Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-030

Text File | 1995-06-07 | 198.0 KB | 5,124 lines | [TEXT/R*ch]

Received-Date: Wed, 25 May 1994 10:42:28 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-030
To: [e-mail]
Date: Wed, 25 May 94 10:42:16 MET DST
X-Mailer: ELM [version 2.3 PL11]
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 33

C.S.M.P. Digest             Wed, 25 May 94       Volume 3 : Issue 30

Today's Topics:

        Apple's blatant disregard for User Interface Guidelines
        List Manager clikLoop problem... but whose it?
        Opening a file with C standard i-o routines
        Sym CDK vs CodeWarrior PPC: first impressions
        Where is the inheritance in AE objects?
        [Q] How to prevent _DragWindow from selecting the window?
        [Q] casting Str255 <--> (char*)



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users as comp.sys.mac.programmer.src.


-------------------------------------------------------

>From [e-mail] (John V. Blzka)
Subject: Apple's blatant disregard for User Interface Guidelines
Date: 2 May 94 15:26:59 GMT
Organization: Chevron, La Habra, CA

Hello,
I've been working on a presentation on Human Factors Engineering.
I am using Apple's User Interface Guidelines as an example.
What I would like to know is:
  Does Apple violate it's own Guidelines in any of it's System 7
  software?
  If so, can I easily demonstrate it?

Thanks in advance,
John
[e-mail]

--
===================================================================
John Blyzka                      | [e-mail]
"the BLITZ"                      | "only the good die young"


+++++++++++++++++++++++++++

>From [e-mail] (Charles Wiltgen)
Date: Tue, 03 May 1994 19:54:07 -0600
Organization: Lederhosen 'R' Us - Worldwide Leaders in Lederhosen

In article <[e-mail]>,
[e-mail] (John V. Blzka) wrote:

> Hello,
> I've been working on a presentation on Human Factors Engineering.
> I am using Apple's User Interface Guidelines as an example.
> What I would like to know is:
>   Does Apple violate it's own Guidelines in any of it's System 7
>   software?
>   If so, can I easily demonstrate it?

How 'bout dragging a disk to the trash to eject it?

--
Charles Wiltgen    "Love is a snowmobile racing across the tundra and
[e-mail]    then suddenly it flips over, pinning you underneath.
(INTP)              At night, the ice weasels come." - Nietzsche (Groening)
World Wide Web      http://venus.mcs.net/~cwiltgen/home.html

+++++++++++++++++++++++++++

>From [e-mail] (Robert S. Mah)
Date: Tue, 03 May 1994 21:57:11 -0500
Organization: One Step Beyond

[e-mail] (Charles Wiltgen) wrote:

> [e-mail] (John V. Blzka) wrote:
>
> > I've been working on a presentation on Human Factors Engineering.
> > I am using Apple's User Interface Guidelines as an example.
> > What I would like to know is:
> >   Does Apple violate it's own Guidelines in any of it's System 7
> >   software?  If so, can I easily demonstrate it?
>
> How 'bout dragging a disk to the trash to eject it?

That is, in fact, a wonderful example of the _process_ of iterative
user interface design.  Complete with pragmatic compromises and soul
searching about paradigm stability and all that.

There was a thread over in comp.human-factors about this where one of
Apple's Human Interface people stopped by and asked for suggestions.
The winner got a T-shirt.  Suffice it to say that no one could come up
with anything better, given the constraints at hand.  It's a pretty
damn tough problem.

Cheers,
Rob
___________________________________________________________________________
Robert S. Mah  -=-  One Step Beyond  -=-  212-947-6507  -=-  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Wed, 4 May 1994 11:13:39 GMT
Organization: PRZ TU-Berlin

[e-mail] (John V. Blzka) asked:
>>   Does Apple violate it's own Guidelines in any of it's System 7
>>   software?
>>   If so, can I easily demonstrate it?

[e-mail] (Charles Wiltgen) replied:
>How 'bout dragging a disk to the trash to eject it?

Although the semantics and history of this gesture have been
much debated, I find myself asking "What Human Interface
Principle does this violate?" It certainly supports the
principles Direct Manipulation, See-and-Point, and User
Control. Admittedly, it weakens the metaphor of trashcan-
as-device-of-destruction, but since that's not what the
trash can is (it's more a metaphor of device-to-get-things
-off-my-desktop) and metaphors are meant to be *extensible*
("Metaphors in the computer interface suggest a use for
something, but that use doesn't define or limit the
implementation of the metaphor", _Macintosh Human Interface
Guidelines_ p. 5), that's not really the problem.

In short, although dragging a disk to the trash (as an
alternative to the Put Away command) may seem to be
a strange gesture, it's not a violation.

As far was the original question is concerned, you
can find a number of violations if you want to nit-pick.
For instance, ResEdit 2.1.1 does not use the new,
canonical layout for its "Maybe you want to save
before closing/quitting?" dialog. Also, some of
the recommendations regarding movabale modal
dialogs and modeless dialogs were slow in percolating
through to the entire system software.

I think, however, you will be hard-pressed to find
a violation in the Finder.

Hope this helps,

--
Peter Castine                      | Da sprach Jesus zu ihm: Stecke dein
[e-mail]          | Schwerdt an seinen Ort; denn wer das
- ---------------------------------| Schwerdt nimmt, der soll durchs
     ``Have Mac, will travel''     | Schwerdt umkommen. (Matthai 26:52)

+++++++++++++++++++++++++++

>From [e-mail] (Graham Cox)
Date: Wed, 4 May 1994 20:24:52 GMT
Organization: School of Information Systems, UEA, Norwich

In article <[e-mail]>, [e-mail]
(Charles Wiltgen) wrote:

> In article <[e-mail]>,
> [e-mail] (John V. Blzka) wrote:
>
> > Hello,
> > I've been working on a presentation on Human Factors Engineering.
> > I am using Apple's User Interface Guidelines as an example.
> > What I would like to know is:
> >   Does Apple violate it's own Guidelines in any of it's System 7
> >   software?
> >   If so, can I easily demonstrate it?
>
> How 'bout dragging a disk to the trash to eject it?


Oh, THAT old chestnut! Be honest- could YOU live without it?

Here's a trivial example- not in the system but in most graphics programs,
including MacDraw and ClarisWorks- the guidelines say that the cursor keys
should never be used to position graphic elements, but most programs do
this. However, in my opinion, it is the guideline that's stupid- WHY NOT!!!



>
> --
> Charles Wiltgen    "Love is a snowmobile racing across the tundra and
> [e-mail]    then suddenly it flips over, pinning you underneath.
> (INTP)              At night, the ice weasels come." - Nietzsche (Groening)
> World Wide Web      http://venus.mcs.net/~cwiltgen/home.html

- ------------------------------------------------------------------------
Love & BSWK, Graham

-Everyone is entitled to their opinion, no matter how wrong they may be...
- ------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Barry Brown)
Date: 4 May 94 17:17:18 GMT
Organization: (none)

In <[e-mail]> [e-mail] (Peter Castine) writes:

>[e-mail] (John V. Blzka) asked:
>>>   Does Apple violate it's own Guidelines in any of it's System 7
>>>   software?
>>>   If so, can I easily demonstrate it?

>[e-mail] (Charles Wiltgen) replied:
>>How 'bout dragging a disk to the trash to eject it?

>Although the semantics and history of this gesture have been
>much debated, I find myself asking "What Human Interface
>Principle does this violate?" It certainly supports the
>principles Direct Manipulation, See-and-Point, and User
>Control.

I believe it violates the (perhaps unwritten) "no surprises" and the "one
object, one action" rules.

A novice user is surprised to find out that trashing a disk doesn't erase
it, but ejects it instead.  S/he also discovers that selecting Eject from
the Special menu doesn't remove the disk image from the desktop and may even
ask him/her for the disk again in the future!

Second, the Trash can is used for two purposes: removing files and ejecting
disks -- two very different actions.  The Trash is just a folder (albeit a
special one); trashed files show up in its window before you empty it.  Why
don't trashed disks show up in it, either?

--
Barry E. Brown                          Internet: [e-mail]
UCSD Academic Computing Services        AOL:      BarryBrown
Student Consultant
<a href="http://www-cse.ucsd.edu/users/bbrown">My WWW Home Page</a>

+++++++++++++++++++++++++++

>From [e-mail] (Bienvenu Jay )
Date: Wed, 4 May 1994 18:06:50 GMT
Organization: Univ. of Southwestern La., Lafayette


Does Claris count as part of Apple?  If so, I've got one:
MacWrite does not display a watch cursor while saving a file.

Jay Bienvenu
[e-mail]

+++++++++++++++++++++++++++

>From Paul Ferguson <[e-mail]>
Date: 4 May 1994 23:48:17 GMT
Organization: Kaleida Labs, Inc.

In article <[e-mail]> John V. Blzka,
[e-mail] writes:
> Does Apple violate it's own Guidelines in any of it's System 7
> software?

One classic example that comes to mind is the Alarm Clock, which
suffers from a bunch of violations:  non-standard controls,
non-standard title bar (not to mention using the title bar to
display the time), non-standard close box, a cross-hair cursor to
select a field, the big-small display modes, flashing the Apple
menu forever when the alarm goes off (how many people at some
point in their life were mystified to see a flashing alarm clock
where the Apple menu is?)  It's hard to find anything about the
alarm clock that doesn't violate the HIG.

Rumor has it that this DA was originally developed by Microsoft,
which might explain some of it.  It has not evolved at all from
it's earliest incarnation, which is pretty lame on Apple's part.
How hard is it to write an alarm clock?

--fergy

+++++++++++++++++++++++++++

>From Brad Koehn <[e-mail]>
Date: 5 May 1994 01:35:32 GMT
Organization: University of Wisconsin

In article <[e-mail]> Peter Castine,
[e-mail] writes:
>I think, however, you will be hard-pressed to find
>a violation in the Finder.

Oh, let's see, where to start:
If you get info on a file on a server, or on a local volume with file
sharing turned on, clicking on the name changes it to it's DOS equivilant.

It doesn't give background applications any time (hardly). I know this
probably isn't spelled out in the HIG, but it should be.

When copying files, the menus don't dim. If you click in the menu bar
during a copy, the dim all of a sudden.

With the sharing box open, there's now way to save changes. You have to
hit the close box, and dismiss the (up to three) annoying dialogs.

Dragging items onto a system folder that's not the one you booted with
doesn't put them in the right place, even if the icons in the folder
(e.g. apple menu items folder) show correctly.

You may call these bugs, but I say bugs are the most obvious form of HIG
violation.
_________________________________________________________________________
Brad Koehn          Data Transformations, Inc.        [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Thu, 05 May 1994 10:03:13 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <[e-mail]>,
[e-mail] (Peter Castine) wrote:

>I think, however, you will be hard-pressed to find
>a violation in the Finder.

OK, I've got a good one!  Why, when you drag a file into a folder where
there already exists a file of the same name, do you have the option of
replacing the original.  Why doesn't the Finder move it to the Trash???
OK, so maybe it's not a *real* HIG violation but it's really inconsistent
and consistency is one of the central precepts of the HIG.

Other (more obvious) problems become apparent when you install PowerTalk.
Try the following...

1) Open your catalogue.
2) Drag a file into the catalogue window.
3) See Finder highlight catalogue window.
4) Let go.
5) See file zoom back to its original position.

Or try this...

1) Open your catalogue.
2) Find a user record (either in your Personal Catalogue or in a
PowerShare catalogue) and drag it to the catalogue window.
3) See Finder highlight catalogue window.
4) Let go.
5) Read dialog telling you that you can't do it because you don't have
privileges.

Question #1 Why does it highlight the window (in both cases)?
Question #2 Why does it have different behaviour when it finally realises
            that it's failed?

Basically AOCE's HI is severely broken in a lot of places.  Unfortunately
it's a Finder extension, which means that these problems appear to be
Finder problems.
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia

+++++++++++++++++++++++++++

>From [e-mail] (Rick Reynolds aka GreenGoo)
Date: Thu, 5 May 1994 06:32:08 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

>How 'bout dragging a disk to the trash to eject it?


I never really thought much about this issue but I think there should
have been a disk drive icon on the desktop, always visable but somehow
conveying to the user that a disk is inserted. When the user wants
to change disks they can press an "eject" button on the icon. But alas
that brings up the problem of having a control (which woule have to be
smaller then other controls) on a Finder icon.

Hmmm...
--
Richard Reynolds
[e-mail]

 "Most dreams are made of glass. You throw just one stone and then there
goes your last window" -RJD


+++++++++++++++++++++++++++

>From [e-mail] (Alan DeGuzman)
Date: 5 May 1994 13:17:32 GMT
Organization: Calculus&Mathematica at UIUC

[e-mail] (Rick Reynolds aka GreenGoo) writes:

>>How 'bout dragging a disk to the trash to eject it?


>I never really thought much about this issue but I think there should
>have been a disk drive icon on the desktop, always visable but somehow
>conveying to the user that a disk is inserted.

Uh, what about the disk's icon? Granted, it can be hidden behind windows,
but I'd rather have what *I* want to stay on top of the desktop layer
rather than some floating icons or whatever.

>When the user wants
>to change disks they can press an "eject" button on the icon. But alas
>that brings up the problem of having a control (which woule have to be
>smaller then other controls) on a Finder icon.

Now you're on to something. How about letting every icon that is a volume
have a 'switch' or 'button' drawn on (or near) the icon that let's you
eject the volume (eject in the sense of "Put Away"). It could even be dimmed
out for volumes that can't be "Put Away", like the startup volume.
--
Alan A. DeGuzman          "The problem with people is that they're only human."
Calculus&Mathematica
DISCLAIMER: "The University         - Hobbes to Calvin from
can't afford my opinions."           'The Indispensible Calvin and Hobbes'

+++++++++++++++++++++++++++

>From [e-mail] (Tim Smith)
Date: 5 May 1994 13:52:44 GMT
Organization: University of Washington School of Law, Class of '95

> I've been working on a presentation on Human Factors Engineering.
> I am using Apple's User Interface Guidelines as an example.
> What I would like to know is:
>   Does Apple violate it's own Guidelines in any of it's System 7
>   software?
>   If so, can I easily demonstrate it?

In the thingy that is used to select a color (get it by selecting "other..."
for your highlight color in the Colors control panel, or double clicking
on a palette entry in the pattern editor in the General control panel),
they use a scroll bar to set brightness.  I think this violates something
in the User Interface Guidelines.

--Tim Smith

+++++++++++++++++++++++++++

>From Thomas Reed <[e-mail]>
Date: 5 May 1994 15:00:06 GMT
Organization: Washington University

In article <2q9ih4$[e-mail]> Brad Koehn,
[e-mail] writes:
>It doesn't give background applications any time (hardly). I know this
>probably isn't spelled out in the HIG, but it should be.

I don't think that this kind of stuff is in the interface guidelines,
though I can't say that for sure.  Actually, the amount of time
background applications get depends on the background application.  Any
application can grab as much or as little of the CPU time as it needs.
That's how the Mac's cooperative multitasking works.

>When copying files, the menus don't dim. If you click in the menu bar
>during a copy, the dim all of a sudden.

I think my menus dim, all except the Apple, Balloon Help, and Application
(you know, the one on the far right) menus.  If they don't dim, it's
probably for one of two reasons:  1)  you can use them even during a
copy, or 2)  you have an extension or control panel installed that does
something with your menus.

>With the sharing box open, there's now way to save changes. You have to
>hit the close box, and dismiss the (up to three) annoying dialogs.

Agreed on this one.  It'd be nice if there was a friendlier way to do
sharing stuff.  Though I'm not going to complain too much -- I don't mind
the way it's done now.

>Dragging items onto a system folder that's not the one you booted with
>doesn't put them in the right place, even if the icons in the folder
>(e.g. apple menu items folder) show correctly.

Yes, I've often done this.  However, there's really only one way for the
computer to know that a folder is the system folder without doing more
stuff than it should have to do -- if it has the active system in it.  If
every time you dropped something in a folder, the system had to search
that folder for a copy of the Finder, then all your moves would take a
little longer.  Not only that, but it wouldn't be reliable -- sometimes I
keep copies of the Finder around in different places to play with them.

-Thomas
=====================================================
Thomas Reed                    Washington University
[e-mail]          Medical School
(also:  [e-mail])
- ---------------------------------------------------
Clothes make the man.  Naked people have little or no
influence on society.  -- Mark Twain
=====================================================

+++++++++++++++++++++++++++

>From Paul Ferguson <[e-mail]>
Date: 5 May 1994 15:30:12 GMT
Organization: Kaleida Labs, Inc.

In article <2qatnc$[e-mail]> Tim Smith, [e-mail]
writes:
> In the thingy that is used to select a color (get it by
> selecting "other..." for your highlight color in the Colors
> control panel, or double clicking on a palette entry in the
> pattern editor in the General control panel), they use a scroll
> bar to set brightness.  I think this violates something in the
> User Interface Guidelines.

HIG page 215: "Use scroll bars only for representing the relative
position of the visible portion of a document and in scrolling
lists."  I suppose one could argue that in the color picker, the
"document" is the entire color space and that you are scrolling
through it to see different views.  On the other hand, what the
slider is doing is changing the brightness from 0-65535, which
is exactly what the example shown on that page says is an incorrect
use of a scroll bar.

This does raise the issue of why Apple explicitly talks about
sliders (in a section entitled "Controls Not Supported by the
Macintosh Toolbox") and gives guidelines as to their use, but have
never provided any sort of standard slider controls for programmers
to use.  Other environments like Motif provide slider widgets with
the same look and feel as their scroll bars, check boxes, etc.  I
think Apple's OS and UI groups have failed by not providing the
same.  Hence the scroll bar often does get misused because it is
much easier to use what's there than write it from scratch (and
writing a smooth slider is not a trivial task).

--fergy

- ------------------------------------------------------------------
  Paul Ferguson         | "It's a sick world, I'm a happy guy..."
  [e-mail] |
- ------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Brian V. Hughes)
Date: 5 May 1994 17:33:26 GMT
Organization: Dartmouth College, Hanover, NH, USA

Thomas Reed <[e-mail]> writes:

>Brad Koehn, [e-mail] writes:
>>It doesn't give background applications any time (hardly). I know this
>>probably isn't spelled out in the HIG, but it should be.

>I don't think that this kind of stuff is in the interface guidelines,
>though I can't say that for sure.

    No it's not in the HIG, but that's because there is no human
interface involved with background applications getting CPU time.

>Actually, the amount of time background applications get depends on the
>background application.  Any application can grab as much or as little
>of the CPU time as it needs.  That's how the Mac's cooperative
>multitasking works.

    Nope, sorry. There's this little routine called WaitNextEvent() that
must be called, at a decent interval, by the forgroung application so
that when the background application calls GetNextEvent() there's
something there to be gotten. Applications have to be written to perform
as both foreground and background apps, nicely, so that the Mac
cooporative scheme works the way it's supposed to.

-Hades

+++++++++++++++++++++++++++

>From Chuck Simciak <[e-mail]>
Date: Thu, 5 May 1994 17:28:00 GMT
Organization: Cleveland Clinic Foundation

In article <2qatnc$[e-mail]> Tim Smith,
[e-mail] writes:
>> I've been working on a presentation on Human Factors Engineering.
>> I am using Apple's User Interface Guidelines as an example.
>> What I would like to know is:
>>   Does Apple violate it's own Guidelines in any of it's System 7
>>   software?
>>   If so, can I easily demonstrate it?

I'm not sure if this counts as breaking an interface guideline but it is
very annonying.  Say I go to save a file, the StandardPutFile dialog
emerges and I have to navigate several folders to get to my desitination.
 The file name field has already been filled with a defualt.  Here's the
catch.  Upon having navigated the multiple folders to place the file, the
SAVE button is now an OPEN button.  I then have to click in the filename
text field to cause the button to CHANGE to SAVE.  This "feature" was
introduced in System 7 and has been a source of nuisance ever since.

later....


    Chuck Simciak      !"The broken image of Man moves in minute by minute
   [e-mail]     ! and cell by cell... Poverty, hatred, war, police-
[e-mail] ! criminals, bureaucracy, insanity, all symptoms of
WRUW 91.1 FM Cleveland ! The Human Virus."          - William S. Burroughs

+++++++++++++++++++++++++++

>From [e-mail] (dn_crow)
Date: Thu, 5 May 1994 18:43:00 GMT
Organization: (none)

An example that has always rather amused me is the one about switching
between applications. The guidlines state that if I click outside any
window belonging to my application, this action should switch me to the
application whose window I have clicked over (e.g. the Finder). The
only action of this click, or indeed double-click, should be to switch
applications. In particular, the guidelines state that the clicks
should *not* be sent to the application being clicked upon.

However, the Finder disregards this: try loading an application and
bringing it to the front, while still being able to see a finder window
behind it. If you now click over a visible finder icon, the appropriate
Finder window is brought to the front (correct) but the icon is
selected (incorrect).

This, along with most of the other problems mentioned in this thread,
is pretty minor, so if, as your rather biased title suggests, you're
trolling for Apple-bashing material, I think you'll have a pretty weak
case...

Dan

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Thu, 5 May 1994 19:48:30 GMT
Organization: PRZ TU-Berlin

[e-mail] (Quinn "The Eskimo!") writes:
>[e-mail] (that's me) wrote:
>
>>I think, however, you will be hard-pressed to find
>>a violation in the Finder.
>
>OK, I've got a good one!  Why, when you drag a file into a folder where
>there already exists a file of the same name, do you have the option of
>replacing the original.  Why doesn't the Finder move it to the Trash???
>OK, so maybe it's not a *real* HIG violation but it's really inconsistent

Inconsistent with what?

>and consistency is one of the central precepts of the HIG.

Consistency is, IMHO, a secondary concern. Smith et.al. discuss the
practical issues of maintaining consistency in real world applications
in their 1982 article "Designing the Star user interface." (Originally
printed in Byte 7(4), reprinted in Baecker & Buxton's _Readings in
Human-Computer Interaction_, the paper is a must-read). Short
precis: consistency is the hobgoblin of small minds.

>Other (more obvious) problems become apparent when you install PowerTalk.

This is cheating--PowerTalk extensions aren't the Finder. I suppose
they look that way, though.

>Try the following...
>
>1) Open your catalogue.
>2) Drag a file into the catalogue window.
>3) See Finder highlight catalogue window.
>4) Let go.
>5) See file zoom back to its original position.
>

This example comes practically straight from the discussion in
the above-mentioned article. Geez--maybe I should just violate
copyright and type in the entire paper.

:-)

>Or try this...
>
>1) Open your catalogue.
>2) Find a user record (either in your Personal Catalogue or in a
>PowerShare catalogue) and drag it to the catalogue window.
>3) See Finder highlight catalogue window.
>4) Let go.
>5) Read dialog telling you that you can't do it because you don't have
>privileges.
>
>Question #1 Why does it highlight the window (in both cases)?

For performance reasons? (Checking privileges might slow down
feedback, direct manipulation. I'm obviously guessing on this one).

>Question #2 Why does it have different behaviour when it finally realises
>            that it's failed?

What's it supposed to do? Not tell you that it failed? Disregard
privileges?

>Basically AOCE's HI is severely broken in a lot of places.

Severely? Well, I'll let that pass before a flame war breaks out.

> Unfortunately
>it's a Finder extension,

Like I said, cheating.

>which means that these problems appear to be
>Finder problems.

Well, touche.

--
Peter Castine                      | Da sprach Jesus zu ihm: Stecke dein
[e-mail]          | Schwerdt an seinen Ort; denn wer das
- ---------------------------------| Schwerdt nimmt, der soll durchs
     ``Have Mac, will travel''     | Schwerdt umkommen. (Matthai 26:52)

+++++++++++++++++++++++++++

>From Thomas Reed <[e-mail]>
Date: 5 May 1994 20:31:38 GMT
Organization: Washington University

In article <[e-mail]> Chuck Simciak,
[e-mail] writes:
> The file name field has already been filled with a defualt.  Here's the
>catch.  Upon having navigated the multiple folders to place the file, the
>SAVE button is now an OPEN button.  I then have to click in the filename
>text field to cause the button to CHANGE to SAVE.  This "feature" was
>introduced in System 7 and has been a source of nuisance ever since.

I believe this problem is caused not by the system, but by Directory
Assistance II.  (Or a similar program.)  My System 7.x machine never did
this until I installed Directory Assistance II, so...

-Thomas
=====================================================
Thomas Reed                    Washington University
[e-mail]          Medical School
(also:  [e-mail])
- ---------------------------------------------------
Clothes make the man.  Naked people have little or no
influence on society.  -- Mark Twain
=====================================================

+++++++++++++++++++++++++++

>From Thomas Reed <[e-mail]>
Date: 5 May 1994 20:48:08 GMT
Organization: Washington University

In article <2qbal6$[e-mail]> Brian V. Hughes,
[e-mail] writes:
>>Actually, the amount of time background applications get depends on the
>>background application.  Any application can grab as much or as little
>>of the CPU time as it needs.  That's how the Mac's cooperative
>>multitasking works.
>
>    Nope, sorry. There's this little routine called WaitNextEvent() that
>must be called, at a decent interval, by the forgroung application so
>that when the background application calls GetNextEvent() there's
>something there to be gotten.

Yes, it's true that there has to be "something to be gotten", but I think
most applications these days, background or not, call WaitNextEvent, so
they can control directly how much time they get by giving different
numbers for the sleep value.  A low value causes the app to be given time
more often, a high value causes the app to be given time less often.
Plus, if the background app doesn't call WaitNextEvent AT ALL for a
while, they get ALL of that processing time.  WaitNextEvent is the key
behind applications getting CPU time.

-Thomas
=====================================================
Thomas Reed                    Washington University
[e-mail]          Medical School
(also:  [e-mail])
- ---------------------------------------------------
Clothes make the man.  Naked people have little or no
influence on society.  -- Mark Twain
=====================================================

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Thu, 5 May 1994 20:39:17 GMT
Organization: PRZ TU-Berlin

Chuck Simciak <[e-mail]> writes:
>
>I'm not sure if this counts as breaking an interface guideline but it is
>very annonying.  Say I go to save a file, the StandardPutFile dialog
>emerges and I have to navigate several folders to get to my desitination.
> The file name field has already been filled with a defualt.  Here's the
>catch.  Upon having navigated the multiple folders to place the file, the
>SAVE button is now an OPEN button.  I then have to click in the filename
>text field to cause the button to CHANGE to SAVE.  This "feature" was
>introduced in System 7 and has been a source of nuisance ever since.

I like this one, because the Standard Save File dialog is being
*consistent* (that's right, folks!).

The Save button only changes to Open when you've selected a folder
in the directory list. When this is the case, the EditText field
with the document name is no longer the active item in the dialog,
the directory list is the active item (highlighted with an extra
two-pixel thick box surrounding it). So, the Save button is being
context-sensitive, changes to 'Open' and behaves the same way
a double-click on the currently selected item would behave.

BTW, you don't need to click on the document name, you only have
to deselect any folder, for the button to change back to Open.

I'm just waiting for someone to say "Why don't they add another
button, so you've got one for Save and one for Open?" Before you
ask that question, read Tognazzini's article on Consistency in
_The Art of Human-Computer Interface Design_ ;-q

--
Peter Castine                      | Da sprach Jesus zu ihm: Stecke dein
[e-mail]          | Schwerdt an seinen Ort; denn wer das
- ---------------------------------| Schwerdt nimmt, der soll durchs
     ``Have Mac, will travel''     | Schwerdt umkommen. (Matthai 26:52)

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Fri, 06 May 1994 10:41:44 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <2qatnc$[e-mail]>, [e-mail] (Tim
Smith) wrote:

>In the thingy that is used to select a color (get it by selecting "other..."
>for your highlight color in the Colors control panel, or double clicking
>on a palette entry in the pattern editor in the General control panel),
>they use a scroll bar to set brightness.  I think this violates something
>in the User Interface Guidelines.

Actually it violates the letter, *but not IMHO the spirit*, of the
guideline that states that you should only put settings, as opposed to
commands, in a popup menu.
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia

+++++++++++++++++++++++++++

>From [e-mail] (Joseph Manuel Finete)
Date: 6 May 1994 03:04:26 GMT
Organization: University of California; Santa Cruz


In article <[e-mail]> [e-mail] (Peter Castine) writes:
>
>I like this one, because the Standard Save File dialog is being
>*consistent* (that's right, folks!).
>
>The Save button only changes to Open when you've selected a folder
>in the directory list. When this is the case, the EditText field
>with the document name is no longer the active item in the dialog,
>the directory list is the active item (highlighted with an extra
>two-pixel thick box surrounding it). So, the Save button is being
>context-sensitive, changes to 'Open' and behaves the same way
>a double-click on the currently selected item would behave.
>
>BTW, you don't need to click on the document name, you only have
>to deselect any folder, for the button to change back to Open.

Also, hitting the TAB key will let you cycle through the dialog items.
So if the file list is selected, hit TAB and then the EditText field
will be selected. My problem is that its not obvious enough that the
file list is selected or that the Edit Text field is not selected,
although, I really don't have a good idea on how to alleviate this.

--
Joe Finete
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 6 May 1994 08:34:14 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> Chuck Simciak <[e-mail]> writes:

>catch.  Upon having navigated the multiple folders to place the file, the
>SAVE button is now an OPEN button.  I then have to click in the filename
>text field to cause the button to CHANGE to SAVE.  This "feature" was

Or you can press TAB. This is so you can actually type-select
folder names in the list, instead of having to use arrow keys.

Cheers,

                    / h+
--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe (on a Swedish scale) --

   What we need is a good GNU [...] licence manager implementation.
                     -- Raphael Manfredi

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 6 May 1994 08:36:21 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] (dn_crow) writes:

>only action of this click, or indeed double-click, should be to switch
>applications. In particular, the guidelines state that the clicks
>should *not* be sent to the application being clicked upon.

This recommendation is going away with the new, direct manipulation,
Drag Manager, and AOCE which uses it (or its cousin) and it will DEFINATELY
not be the case when you run OpenDoc.

Cheers,

                    / h+
--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe (on a Swedish scale) --

   What we need is a good GNU [...] licence manager implementation.
                     -- Raphael Manfredi

+++++++++++++++++++++++++++

>From [e-mail] (Sak Wathanasin)
Date: Fri, 6 May 94 09:47:25 GMT
Organization: Network Analysis Ltd


In article <[e-mail]> (comp.sys.mac.advocacy,comp.sys.mac.programmer), [e-mail] (dn_crow) writes:

> applications. In particular, the guidelines state that the clicks
> should *not* be sent to the application being clicked upon.

As with all guidelines, this is not meant to be slavishly adhered to.
It's up to the appl whether to accept the first click, and in the case
of the Finder what it does makes a lot of sense. Although the desktop
is a window in some sense, in a way it isn't. You have to select a piece
of paper (window) to write in it, but surely you don't expect to
"select" your desk to pick something up or put it down. (I'd also argue
that you should be able to "click through" to most appls, just like I can
scribble a note in the margin of a sheet of paper without having to move it
to the front, but that's another story.)

The Finder also does the same with folder windows. Does anyone remember
what it used to be like? When you wanted to drag a file from one folder
to another, you clicked on the src icon which would bring its window to
the front. This would sometimes cover up the window you wanted to drag
to, so you'd have to go back and move it out from underneath (then move
it back after the drag if you're obsessively tidy like me :-). The way
it does it now is MUCH better, and I'm pleased to see that the Drag Mgr
supports this way of working. If the guidelines say that you can't do
this, then the guidelines should be changed.


Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [e-mail]
uucp:     ...!uknet!nan!sw                       AppleLink: NAN.LTD
Phone: [phone] Mobile:[phone]  Fax: [phone]

+++++++++++++++++++++++++++

>From Willie Abrams <[e-mail]>
Date: 5 May 1994 15:02:28 GMT
Organization: OU Health Sciences Center

In article <[e-mail]> Quinn,
[e-mail] writes:
>Basically AOCE's HI is severely broken in a lot of places.  Unfortunately

AOCE is real screwed up as far as HIG goes. If we are going to
flame its flaws, here are my complaints:

The standard mailer is a specific size, which means if you
make the window smaller, it cuts off the damn mailer, and
if you make the window bigger, you can't take advantage
of the extra space to the right of the mailer.

The way the mailer is shaped, You can only see about three
enclosures...

AppleMail has a real sluggish event loop. I know this isn't
necessarily a HIG flaw, but it is a real UI flaw. I end up
reading mail in ClarisWorks, since it responds to my stimulus
faster.

PowerShare admin stuff is just plain ugly. Chicago and Geneva
are the System and Application typefaces for a reason - they
are readable on screen. This Palatino stuff, with fixed sixed
panes are a real pain. At least with AppleShare, you had nice
resizeable and movable lists that allowed you to manage it.
(although it didn't remember window positions...ugh!)

I can move the keys off the desktop, but I can't move the
catalogs (I guess I can sort of see that) - QuickDraw GX
suffers there too, with all of those desktop printers...a
real pain in the butt for those of use who move frequently
from enviroment to enviroment with the same system.

Another UI problem - Symantec/Think C - I can't open a source
file without opening a project. Great! Modal Functionality...
Probably why I like Metrowerks...

Is there a forum where people can talk and discuss about
UI issues? Would that be a thread that should be here in csmp?

I think we have a real opportunity to jolt some people back
into thinking about how software is used. There are real
usability issues that are not related to functionality that
need to be addressed.

We as programmers need to address these head on, as we implement
the great (or horrid) user interfaces.

I will stop now. I am getting incensed.

Willie Abrams
Telemedicine Software Guy  Internet:  [e-mail]
OU Health Sciences Center  AppleLink: Willie

+++++++++++++++++++++++++++

>From John Hamilton Slye <[e-mail]>
Date: Fri,  6 May 1994 12:55:38 -0400
Organization: Junior, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA

On 06-May-94 in Re: Apple's blatant disrega..
user Joseph Manuel Finete@cat writes:
>Also, hitting the TAB key will let you cycle through the dialog items.
>So if the file list is selected, hit TAB and then the EditText field
>will be selected. My problem is that its not obvious enough that the
>file list is selected or that the Edit Text field is not selected,
>although, I really don't have a good idea on how to alleviate this.

When the test field is not selected, the caret isn't in it anymore...and
when the file list is selected, there is an outline box around it...


O------------------O---------------------O----------------------------------O
|                  | [e-mail] | "I know that there are people in |
| J. Hamilton Slye |                     | the world who do not love their  |
|                  |   [e-mail]   | fellow human beings...and I HATE |
O------------------O---------------------O people like that!"               |
|          1071 Morewood Ave.            |              - Tom Lehrer        |
|         Pittsburgh, Pa. 15213          O----------------------------------O
|            [phone]              |       THIS SPACE FOR RENT!       |
O----------------------------------------O----------------------------------O

+++++++++++++++++++++++++++

>From Robert Hess <[e-mail]>
Date: Fri, 6 May 1994 18:44:40 GMT
Organization: MacWEEK

In article <[e-mail]> Quinn, [e-mail] writes:
>Other (more obvious) problems become apparent when you install PowerTalk.

Oh, I have an even better one...

A letter sits in the In Tray. I drag it out of the In Tray into a folder. Have I
moved the letter? No, I've copied it.

The copied letter and the letter remaining in the In Tray, appear to be identical
(same icon, same name). In one window I can see the sender date sent, etc. In
another window I see size, date modified, etc. Can I modify the name of something
in the In Tray? No. How about in a folder? Yes. Can I move something from a
folder back into the In Tray? No.

I love PowerTalk but it imposes a whole set of new (i.e. inconsistent) rules on
new users and, like you said, makes the Finder seem awkward.

========================================================================
Robert Hess, WEEKgeek                      [e-mail]
MacWEEK                                    AppleLink: WNDZSX
301 Howard                                 CompuServe: 72511,333
San Francisco, Calif. 94105                America Online: MacWEEK
[phone] days                        MCI: RHESS
[phone] fax
[phone] nights                      I speak for myself.
now doesn't that make you feel better?     And sometimes not even that.
========================================================================

+++++++++++++++++++++++++++

>From Robert Hess <[e-mail]>
Date: Fri, 6 May 1994 18:46:25 GMT
Organization: MacWEEK

In article <[e-mail]> Quinn, [e-mail] writes:
>1) Open your catalogue.
>2) Find a user record (either in your Personal Catalogue or in a
>PowerShare catalogue) and drag it to the catalogue window.
>3) See Finder highlight catalogue window.
>4) Let go.
>5) Read dialog telling you that you can't do it because you don't have
>privileges.

Or, better yet, drag a user record into the "mount points" list of the File
Sharing Monitor. It hightlights, indicating it is willing to accept a drag. Why
on Earth would it do that? (Or, for that matter, why would someone try to do
this? But that's not the point. ;)

========================================================================
Robert Hess, WEEKgeek                      [e-mail]
MacWEEK                                    AppleLink: WNDZSX
301 Howard                                 CompuServe: 72511,333
San Francisco, Calif. 94105                America Online: MacWEEK
[phone] days                        MCI: RHESS
[phone] fax
[phone] nights                      I speak for myself.
now doesn't that make you feel better?     And sometimes not even that.
========================================================================

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Fri, 6 May 1994 19:43:02 GMT
Organization: PRZ TU-Berlin

Willie Abrams <[e-mail]> writes:
>
>Is there a forum where people can talk and discuss about
>UI issues? Would that be a thread that should be here in csmp?
>

How about comp.human-factors? That might have been a more appropriate
place to follow-up.

--
Peter Castine                      | Da sprach Jesus zu ihm: Stecke dein
[e-mail]          | Schwerdt an seinen Ort; denn wer das
- ---------------------------------| Schwerdt nimmt, der soll durchs
     ``Have Mac, will travel''     | Schwerdt umkommen. (Matthai 26:52)

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Fri, 6 May 1994 20:03:56 GMT
Organization: PRZ TU-Berlin

Joseph Manuel Finete@cat writes:
>>Also, hitting the TAB key will let you cycle through the dialog items.
>>So if the file list is selected, hit TAB and then the EditText field
>>will be selected. My problem is that its not obvious enough that the
>>file list is selected or that the Edit Text field is not selected,
>>although, I really don't have a good idea on how to alleviate this.

John Hamilton Slye <[e-mail]> responded:
>
>When the test field is not selected, the caret isn't in it anymore...and
>when the file list is selected, there is an outline box around it...

I think Joseph may have been aware of this behavior. It is, however, a
bit on the subtle side. It becomes more obvious when the EditText
field is entirely selected, because it highlights/unhighlights when
you tab in and out of it.
--
Peter Castine                      | Da sprach Jesus zu ihm: Stecke dein
[e-mail]          | Schwerdt an seinen Ort; denn wer das
- ---------------------------------| Schwerdt nimmt, der soll durchs
     ``Have Mac, will travel''     | Schwerdt umkommen. (Matthai 26:52)

+++++++++++++++++++++++++++

>From [e-mail] (Jaeger)
Date: Fri, 06 May 94 13:20:30 CDT
Organization: Kunikpok Kennels and Komputers (Pet Project)

Here's a blatantly diregarded interface guidline.  When formatting
floppies there is no progress indicator.  Anything that takes as long as
formatting a floppy should have a progress bar.

Brian  Stern  :-{)}
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Mike Callaghan)
Date: Fri, 6 May 1994 21:51:04 GMT
Organization: MV Communications, Inc.

In article <[e-mail]>,
dn_crow <[e-mail]> wrote:
>However, the Finder disregards this: try loading an application and
>bringing it to the front, while still being able to see a finder window
>behind it. If you now click over a visible finder icon, the appropriate
>Finder window is brought to the front (correct) but the icon is
>selected (incorrect).

If I'm not mistaken, this is simple to correct with ResEdit by changing
the Finder's SIZE resource (Get Front Clicks, I believe). Personally, I
like it, and wish more programs did it.

MikeC
--
Michael D. Callaghan                             Nashua, New Hampshire
- --------------------------------------------------------------------
RULE: "(sqrt(-1)) before (2.71828), except after (186,000 miles/sec)."
            [THE DANGERS OF MIXING GRAMMAR AND SCIENCE]

+++++++++++++++++++++++++++

>From [e-mail] (Graham Keith Rogers - SCLG)
Date: 7 May 1994 02:06:49 GMT
Organization: Mahidol University, Thailand.

Paul Ferguson ([e-mail]) wrote:
: select a field, the big-small display modes, flashing the Apple
: menu forever when the alarm goes off (how many people at some
: point in their life were mystified to see a flashing alarm clock
: where the Apple menu is?)  It's hard to find anything about the

Is *that* what that is.  Jeez, how do I turn it off?  Please....

Graham

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 7 May 1994 09:03:08 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> Robert Hess <[e-mail]> writes:

>A letter sits in the In Tray. I drag it out of the In Tray into a folder. Have I
>moved the letter? No, I've copied it.

Of course! It's the same thing as "a file is sitting on a floppy
disk, and I drag it to a folder on my hard disk."

However, QuickDraw GX desktop printers are another thing:

A file sits in the printer queue, and I drag it to the desktop.
It is MOVED there.
I then drag it to the printer again, and it is COPIED into the
printer.
It makes sense, of course, since moving it to the printer would
delete it once it was printed, but it's still eerie.

--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe (on a Swedish scale) --
  "Anyone who tries to make a distinction between education and
   entertainment doesn't know the first thing about either"
                     -- Trip Hawkins

+++++++++++++++++++++++++++

>From [e-mail] (Tim Smith)
Date: 7 May 1994 09:46:06 GMT
Organization: University of Washington School of Law, Class of '95

Quinn "The Eskimo!" <[e-mail]> wrote:
>>In the thingy that is used to select a color (get it by selecting "other..."
>>for your highlight color in the Colors control panel, or double clicking
>>on a palette entry in the pattern editor in the General control panel),
>>they use a scroll bar to set brightness.  I think this violates something
>>in the User Interface Guidelines.
>
>Actually it violates the letter, *but not IMHO the spirit*, of the
>guideline that states that you should only put settings, as opposed to
>commands, in a popup menu.

I was thinking of page 215, where it says that scroll bars are *only* to
be used to manipulate the relative position in a document or list.  They
explicitly say that scroll bars are not to be used where sliders should
be used.  Thus, the color selector is a blatant violation.

--Tim Smith

+++++++++++++++++++++++++++

>From [e-mail] (Joseph Hall)
Date: Fri, 6 May 1994 17:11:28 GMT
Organization: Motorola Inc., Satellite Communications

Seems it was [e-mail] (dn_crow) who said:
>An example that has always rather amused me is the one about switching
>between applications. The guidlines state that if I click outside any
>window belonging to my application, this action should switch me to the
>application whose window I have clicked over (e.g. the Finder). The
>only action of this click, or indeed double-click, should be to switch
>applications. In particular, the guidelines state that the clicks
>should *not* be sent to the application being clicked upon.

Is this correct?  There is one of the finder flags (the application
bits you can change with ResEdit) that can be set so that the click
will be delivered to the application after it is brought to the front.
I have found this a very appropriate behavior in the case of apps like
THINK Reference.  You click on the "thinker" icon in the background, and
wham, there's THINK Reference for you.

--
Joseph Nathan Hall | Joseph's Law of Interface Design: Never give your users
Software Architect | a choice between the easy way and the right way.
Gorca Systems Inc. |                 [e-mail] (home)
(on assignment)    | [phone] (work)  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Derek LeLash)
Date: Sat, 7 May 1994 18:07:00 GMT
Organization: Corner of Walk & Don't Walk

In article <johan.solve-060594152443@js_mac.hh.se> [e-mail] (Johan Solve) writes:
>
>Metaphors that needs to be explained (as the trashcan in the remove-disk
>case) are not good metaphors. Picture a new user who has never seen a Mac
>before. He inserts a disk and wants to get it out again. I don't think he
>even dare to think of dragging it to the trash. There has to be a Mac guru
>around to explain to him that "in this special case, nothing gets deleted.
>But the disk will disappear from the desktop (and reappear on the real life
>desktop...)"
>
>Not good.

No.  The user selects the disk icon and chooses "Put Away" from the File menu.
Anything else is an optional short cut.  Does the fact that *everyone* drags
disks to the Trash *regardless* of how "pure" the metaphor is tell you anything
about how the Finder was designed to give users multiple ways to perform an
action, so that they can pick the one they want?  I guarantee you that five
minutes after someone learns that you *can* (not *must*) eject a disk by
throwing it in the trash, that will be the only method they ever use.  Who
cares if the metaphor is perfect?

Derek
--
Derek LeLash, SrTechWriter/INFP | "Everyone lays off their Prozac for a week
BASYS Automation Systems, Inc.  |  before I come to town.  Nothing serious,
home: [e-mail]          |  just enough to get a little dip going."
work: [e-mail] |                            -- Shawn Colvin

+++++++++++++++++++++++++++

>From [e-mail] (Dana S Emery)
Date: Sat, 07 May 1994 15:54:44 -0500
Organization: Botany, UMCP

In article <[e-mail]>, Thomas Reed
<[e-mail]> wrote:

> >Dragging items onto a system folder that's not the one you booted with
> >doesn't put them in the right place, even if the icons in the folder
> >(e.g. apple menu items folder) show correctly.
>
> Yes, I've often done this.  However, there's really only one way for the
> computer to know that a folder is the system folder without doing more
> stuff than it should have to do -- if it has the active system in it.

disagree, the Finder already knows if a viable system is inside, it has to
in order to show the proper icon for a system folder.

The rest is simply a matter of searching for tagged folders and directing
the files, and I, as a user would expect that behaviour to be consistant
for any folder showing the blessed system icon, no matter if it was in fact

the booted system.
--

Dana S Emery <[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 8 May 1994 10:09:08 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] (Dana S Emery) writes:

>disagree, the Finder already knows if a viable system is inside, it has to
>in order to show the proper icon for a system folder.

So far so good.

>The rest is simply a matter of searching for tagged folders and directing
>the files, and I, as a user would expect that behaviour to be consistant
>for any folder showing the blessed system icon, no matter if it was in fact
>the booted system.

Exactly how would the Swedish Finder know about the names of the
Hindu special folders?

Cheers,

                    / h+
--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe (on a Swedish scale) --

   There's no sex act that can't be made better with Jell-O.

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Mon, 09 May 1994 10:34:31 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <2qfo0u$[e-mail]>, [e-mail] (Tim
Smith) wrote:

>Quinn "The Eskimo!" <[e-mail]> wrote:
>>Someone else wrote:
>>>In the thingy that is used to select a color (get it by selecting "other..."
>>>for your highlight color in the Colors control panel, or double clicking
>>>on a palette entry in the pattern editor in the General control panel),
>>>they use a scroll bar to set brightness.  I think this violates something
>>>in the User Interface Guidelines.
>>
>>Actually it violates the letter, *but not IMHO the spirit*, of the
>>guideline that states that you should only put settings, as opposed to
>>commands, in a popup menu.
>
>I was thinking of page 215, where it says that scroll bars are *only* to
>be used to manipulate the relative position in a document or list.

True enough.  [Whoops, forgot to *read* the post!]  I was talking about
the "Other..." on the popup menu, not the scroll bars for selecting
values.  The scroll bars are obviouly broken.

btw This "thingy" is called the Colour Picker.
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia
  Repeat 100 times... I will read the post before replying.

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Mon, 09 May 1994 10:56:32 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <[e-mail]>,
[e-mail] (Peter Castine) wrote:

>[e-mail] (Quinn "The Eskimo!") writes:
>>[e-mail] (that's me) wrote:
>>
>>>I think, however, you will be hard-pressed to find
>>>a violation in the Finder.
>>
>>OK, I've got a good one!  Why, when you drag a file into a folder where
>>there already exists a file of the same name, do you have the option of
>>replacing the original.  Why doesn't the Finder move it to the Trash???
>>OK, so maybe it's not a *real* HIG violation but it's really inconsistent
>
>Inconsistent with what?

Inconsistent with the fact that every other time you try to delete a file
in the Finder you have a chance to undo that action by dragging it out of
the Trash.

>>and consistency is one of the central precepts of the HIG.
>
>Consistency is, IMHO, a secondary concern. Smith et.al. discuss the
>practical issues of maintaining consistency in real world applications
>in their 1982 article "Designing the Star user interface." (Originally
>printed in Byte 7(4), reprinted in Baecker & Buxton's _Readings in
>Human-Computer Interaction_, the paper is a must-read). Short
>precis: consistency is the hobgoblin of small minds.

No, *mindless* adherence to consistency is the hobgoblin of small minds.

Actually I'd like to know where you precis comes from because my copy of
Smitch et al says...

%Everyone agrees that consistency is an admirable goal.  However, it
%is perhaps the single hardest characterist of all to achieve in a
%a computer system.  In fact, in systems of even moderate complexity,
%consistency may not be well defined.

The fact that seemingly inconsistent behaviour may be good for the user
(eg their classic drog document on printer example, also dragging floppies
to the Trash) doesn't imply that you shouldn't evaluate your behaviour in
terms of the consistent environment you're creating.  Besides the
behaviour I advocate (moving replaced files to the Trash) is simply better
than the alternative (deleting them).  Are you arguing otherwise?

If so then you're arguing directly with the HIG, which advocate
"Forgiveness" (p10) and says...

#You can encourage people to explore your application by building in
#forgiveness.  Forgiveness means that actions on the computer are
#generally reversible.  People need to feel that they can try things
#without damaging the system; /create safety nets/ for people so that
#they feel comfortable learning and using your product. [my italics]

>>Question #1 Why does it highlight the window (in both cases)?
>
>For performance reasons? (Checking privileges might slow down
>feedback, direct manipulation. I'm obviously guessing on this one).

Personally I think that's crap -- but I don't know enough about AOCE
programming to prove it (:

>>Question #2 Why does it have different behaviour when it finally realises
>>            that it's failed?
>
>What's it supposed to do? Not tell you that it failed? Disregard
>privileges?

Yeah, but why *2* different behaviours?

>>Basically AOCE's HI is severely broken in a lot of places.
>
>Severely? Well, I'll let that pass before a flame war breaks out.

Well I've got some support out there; see the comments by Willie Abrams
<[e-mail]>.
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia

+++++++++++++++++++++++++++

>From [e-mail] (Nicholas James HOWDEN)
Date: Mon, 9 May 1994 04:16:44 GMT
Organization: Computer Science, University of Melbourne, Australia

Paul Ferguson <[e-mail]> writes:

>In article <[e-mail]> John V. Blzka,
>[e-mail] writes:
>> Does Apple violate it's own Guidelines in any of it's System 7
>> software?

>One classic example that comes to mind is the Alarm Clock, which
>suffers from a bunch of violations:  non-standard controls,
    ...
>point in their life were mystified to see a flashing alarm clock
>where the Apple menu is?)  It's hard to find anything about the
>alarm clock that doesn't violate the HIG.

Another good one is when someone sets the alarm clock, but then removes the
item from the apple menu after it goes off. You then have a flashing alarm
clock in the apple menu with no way to turn it off (this certainly sounds
like a Micro$oft 'feature' to me ;-)

Nick.
--

- -----------------------------------------------------------------------------
********   I F   Y O U   Q U I T ,   Y O U ' L L   N E V E R   W I N   ********
- -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Tim Smith)
Date: 9 May 1994 07:49:53 GMT
Organization: University of Washington School of Law, Class of '95

Thomas Reed  <[e-mail]> wrote:
>>Dragging items onto a system folder that's not the one you booted with
>>doesn't put them in the right place, even if the icons in the folder
>>(e.g. apple menu items folder) show correctly.
>
>Yes, I've often done this.  However, there's really only one way for the
>computer to know that a folder is the system folder without doing more
>stuff than it should have to do -- if it has the active system in it.  If
>every time you dropped something in a folder, the system had to search
>that folder for a copy of the Finder, then all your moves would take a
>little longer.  Not only that, but it wouldn't be reliable -- sometimes I

It would only have to do this when you dropped an extension, control panel,
or other magic file into a folder.  For most dropping, it doesn't matter
if the destination is a System Folder, so it would not have to do more
work in the vast majority of cases.

--Tim Smith

+++++++++++++++++++++++++++

>From [e-mail] (dn_crow)
Date: Mon, 9 May 1994 08:43:17 GMT
Organization: (none)

In article <[e-mail]>
[e-mail] (James Miller) writes:

> In article <[e-mail]>, [e-mail]
> (dn_crow) wrote:
>
> > However, the Finder disregards this: try loading an application and
> > bringing it to the front, while still being able to see a finder window
> > behind it. If you now click over a visible finder icon, the appropriate
> > Finder window is brought to the front (correct) but the icon is
> > selected (incorrect).
>
> The Finder is not really an application in Apple's eyes, it is the user
> interface to the system.  The reason an icon will stay selected when
> another window is brought to the front, is to allow it to more easily copy
> files from one window to another.

I'm not arguing that Apple is *wrong* to make the Finder work this way:
personally, I would like all applications to work like this as I find
it very useful. OTOH, I can also see why you don't want to do this:
there are some applications where I need to see the whole window before
deciding where I click on it, and having to click on the window border
to bring it to the front would be a pain. Sigh. An insoluable problem,
probably.

However right Apple may be in their decision, they are still
inconsitent with their own HIGs (which apply to the User Interface of
the whole system: Finder and applications alike).

Dan


+++++++++++++++++++++++++++

>From [e-mail] (Marcel Blonk)
Date: Mon, 9 May 1994 09:51:40 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

Maybe this should come under the header of "Apple's blatant disregard for
User Opinions"

In this thread there have been many complaints about the AOCE UI. Not at
all unwaranted IMO. My $.02 on this: before AOCE was released, it was
shown a couple of times on the WWDC. I, and many others that I've talked
to, always found that the interface needed *major* changes (desktop
clutter/finderlookalikebutnotthesameafterall type things). These concerns
were often voiced, in the different AOCE forums and workgroups. To apple
in general and to the development team in particular. Yet, it was released
with all the same UI problems that people (in this case, developers
mostly) complained about.

What up with that????

To me it seems that Apple has entered a stage, in which the big company
mentality is slowly creeping in, in which each little department has it's
own little territory to defend and defend it they shall, against every one
who'd dare challenge them on their terrain (just one example: how come
something like AppendDITL is part of the comm toolbox! It's a generic
routine, that has NOTHING to do with communications. If the CTB group
wanted this routine to be added, it should have been added in a generic
place, NOT the CTB toolbox. What if the already poorly supported CTB
becomes extinct or replaced by something better? Would the system still
have to support CTB just for the xxxDITL routines (which probably are
being used by programs that have nothing to do with the CTB, since they
are documented as dialog manager extensions)). We see it all the time,
different systems extensions are released, and each uses its own (
different) interface philosophy. There is no consistancy between them
anymore.

In several workgroup discussions at the WWDC, I found that the teams
showed a certain resistance to remarks coming from the developers like:
"wouldn't it be better to combine/make consistant/integrate x with y"
where x was developed by a different group than y (again, the AOCE group
showed this quite distinctively).

Is this the end of the Apple we once knew and loved? Is Apple after all,
just another company grown big, rigid and more guided by internal politics
than by the drive for a better product? I don't know, but that is what I
fear is happening.

Oops, guess I dropped a few cents more then I was planning to.

mb

+++++++++++++++++++++++++++

>From [e-mail] (Pete Resnick)
Date: Mon, 09 May 1994 11:15:33 -0500
Organization: University of Illinois at Urbana-Champaign

In article <[e-mail]>,
[e-mail] (Graham Cox) wrote:

>Here's a trivial example- not in the system but in most graphics programs,
>including MacDraw and ClarisWorks- the guidelines say that the cursor keys
>should never be used to position graphic elements, but most programs do
>this.

That's simply false. From the Macintosh Human Interface Guidlines, chapter 10:

    In a graphics application, the arrow keys can be used for fine movement of
    selected objects, particularly since graphics applications typically have
    no insertion point. If a graphics application uses arrow keys, it should
    be only to move the selected object by the smallest possible increment
    (one pixel or one grid unit). For example, the user could select an object
    and use the arrow keys to move one pixel per keystroke in the direction of
    the arrow key pressed.

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Pete Resnick)
Date: Mon, 09 May 1994 11:23:16 -0500
Organization: University of Illinois at Urbana-Champaign

In article <2qido4$[e-mail]>, [e-mail] (Jon Wdtte)
wrote:

>In <[e-mail]> [e-mail] (Dana S
Emery) writes:
>
>>disagree, the Finder already knows if a viable system is inside, it has to
>>in order to show the proper icon for a system folder.
>
>So far so good.
>
>>The rest is simply a matter of searching for tagged folders and directing
>>the files, and I, as a user would expect that behaviour to be consistant
>>for any folder showing the blessed system icon, no matter if it was in fact
>>the booted system.
>
>Exactly how would the Swedish Finder know about the names of the
>Hindu special folders?

The same way it knows what the names of the Swedish special folders are:

    GetResource('fld#', 0);

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John F. Woods)
Date: 9 May 1994 20:36:43 GMT
Organization: Kendall Square Research

[e-mail] (Johan Solve) writes:
>etaphors that needs to be explained (as the trashcan in the remove-disk
<case) are not good metaphors. Picture a new user who has never seen a Mac
>before. He inserts a disk and wants to get it out again. I don't think he
<even dare to think of dragging it to the trash. There has to be a Mac guru
>around to explain to him that "in this special case, nothing gets deleted.
<But the disk will disappear from the desktop (and reappear on the real life
>desktop...)"

Let's remember how this came about.  Originally you ejected disks by selecting
Eject from the menu (or typing command-E); this left a ghost image that had
to be thrown away.  A lot of people asked for a short cut, and the obvious one
was the one chosen.  Of course, if you don't KNOW what it's a shortcut for,
it does seem to mean something else.

On the other hand, if you had an Ejector on the desktop, what would it mean to
drag an ordinary file onto it?

+++++++++++++++++++++++++++

>From [e-mail] (Maynard James Handley)
Date: Mon, 9 May 1994 22:49:13 GMT
Organization: University of Otago

Tim Smith ([e-mail]) wrote:
> Quinn "The Eskimo!" <[e-mail]> wrote:
> >>In the thingy that is used to select a color (get it by selecting "other..."
> >>for your highlight color in the Colors control panel, or double clicking
> >>on a palette entry in the pattern editor in the General control panel),
> >>they use a scroll bar to set brightness.  I think this violates something
> >>in the User Interface Guidelines.
> >
> >Actually it violates the letter, *but not IMHO the spirit*, of the
> >guideline that states that you should only put settings, as opposed to
> >commands, in a popup menu.

> I was thinking of page 215, where it says that scroll bars are *only* to
> be used to manipulate the relative position in a document or list.  They
> explicitly say that scroll bars are not to be used where sliders should
> be used.  Thus, the color selector is a blatant violation.

> --Tim Smith

I just want to add two point.
Firstly, this use of a scroll bar to select the color may seem a minor matter,
but I have found it really irritating over and over. It should be fixed by
Apple even if it seems silly.
Secondly, Apple have been really dumb by not releasing the slider CDEF inti
the system, like they did with the PopupMenu CDEF. If they added this to the
system so that programmers could trivially access and use it, problems like
this would go away.

Maynard Handley

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Tue, 10 May 1994 11:23:03 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <[e-mail]>, [e-mail] (Marcel
Blonk) wrote:

>Is this the end of the Apple we once knew and loved? Is Apple after all,
>just another company grown big, rigid and more guided by internal politics
>than by the drive for a better product?

I thought "guided by internal politics" *was* the Apple we once knew and
loved (:
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia

+++++++++++++++++++++++++++

>From [e-mail] (Robert S. Mah)
Date: Tue, 10 May 1994 01:48:31 -0500
Organization: One Step Beyond

[e-mail] (Maynard James Handley) wrote:

> Secondly, Apple have been really dumb by not releasing the slider CDEF
> into the system, like they did with the PopupMenu CDEF. If they added
> this to the system so that programmers could trivially access and use
> it, problems like this would go away.

Agreed.  Also why were the little up/down arrow thingies never rolled into
the system?  I guess we'll never know...

Also, I never did quite understand why both push buttons, radio buttons,
check boxes and scroll bars were all rolled into one CDEF.  If _I_ were
designing things, I would have put buttons into 1, radio buttons and check
boxes in another and scroll bars in a third.  Good thing they didn't let
me do this :-).

Cheers,
Rob
___________________________________________________________________________
Robert S. Mah  -=-  One Step Beyond  -=-  212-947-6507  -=-  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Alan DeGuzman)
Date: 10 May 1994 07:21:34 GMT
Organization: Calculus&Mathematica at UIUC

[e-mail] (John F. Woods) writes:

[snip]

>On the other hand, if you had an Ejector on the desktop, what would it mean to
>drag an ordinary file onto it?

Nothing. If this Ejector was written only to eject volumes, the Ejector's
icon would not darken if a file was dragged onto it.
--
Alan A. DeGuzman                  "The problem with the future is that it
Calculus&Mathematica               keeps turning into the present."
DISCLAIMER: "The University
can't afford my opinions."                     - Calvin to Hobbes

+++++++++++++++++++++++++++

>From [e-mail] (Greg Marriott)
Date: Tue, 10 May 1994 09:09:44 -0800
Organization: General Magic, Inc.

[e-mail] (Robert S. Mah) wrote:

> Also, I never did quite understand why both push buttons, radio buttons,
> check boxes and scroll bars were all rolled into one CDEF.

They weren't.  Buttons are in one CDEF and the scrollbar is in another.

> I would have put buttons into 1, radio buttons and check
> boxes in another and scroll bars in a third.

Separating the buttons would have been a good idea, but it's not so bad the
way it is since there's a bunch of common code that is shared.

--
Greg Marriott
Just Some Guy
General Magic, Inc.

Disclaimer: My opinions are not necessarily the same as General Magic's.
            (can a company even HAVE an opinion?)

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Tue, 10 May 1994 17:47:24 GMT
Organization: Apple Computer

Thomas Reed, [e-mail] writes:
> Yes, it's true that there has to be "something to be gotten", but I think
> most applications these days, background or not, call WaitNextEvent, so
> they can control directly how much time they get by giving different
> numbers for the sleep value.

Yes, but if the front app is calling WNE with a very small sleep time -- like
zero -- then there will be much less time for bg apps to run unless they do
something evil like running for several seconds at a time without calling WNE.
  The foreground app should always use a sleep time of infinity unless it
needs to be doing something periodically like blink an i-beam or check for
modifier key changes, and even then it should sleep at least 15 ticks or so
at a time (depending on GetCaretTime, of course.)

That said, does the Finder really call WNE with a zero sleep time? I'd be
surprised if it did.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Tue, 10 May 1994 18:17:22 GMT
Organization: Apple Computer

Paul Ferguson, [e-mail] writes:
> On the other hand, what the
> slider is doing is changing the brightness from 0-65535, which
> is exactly what the example shown on that page says is an incorrect
> use of a scroll bar.

That's the old color picker. If you install ColorSync you get the New &
Improved, All Singing All Dancing color picker, which is much, much nicer and
features sliders instead of scrollbars.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Gary Kacmarcik)
Date: 10 May 1994 22:11:36 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)


In article <[e-mail]> [e-mail] (Robert S. Mah) writes:
> Also, I never did quite understand why both push buttons, radio buttons,
> check boxes and scroll bars were all rolled into one CDEF.  If _I_ were
> designing things, I would have put buttons into 1, radio buttons and check
> boxes in another and scroll bars in a third.  Good thing they didn't let
> me do this :-).

push buttons, check boxes and radio buttons are in one CDEF (CDEF 0, with
variation codes of 0, 1 and 2, respectively)

scrollbars are in a separate CDEF (CDEF 1)

-gary j kacmarcik
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Robert S. Mah)
Date: Tue, 10 May 1994 19:10:18 -0500
Organization: One Step Beyond

[e-mail] (Greg Marriott) wrote:

> [e-mail] (Robert S. Mah) wrote:
>
> > Also, I never did quite understand why both push buttons, radio buttons,
> > check boxes and scroll bars were all rolled into one CDEF.
>
> They weren't.  Buttons are in one CDEF and the scrollbar is in another.

Woops!  You are quite right.  I don't know why I thought that until you
pointed out the error of my ways...


> > I would have put buttons into 1, radio buttons and check
> > boxes in another and scroll bars in a third.
>
> Separating the buttons would have been a good idea, but it's not so bad
> the way it is since there's a bunch of common code that is shared.

Yes, I understand that many compromises had to be made to fit the original
Mac OS into a scant 64K of ROM and 128K of RAM.  That they did it was a
marvel.

Cheers,
Rob
___________________________________________________________________________
Robert S. Mah  -=-  One Step Beyond  -=-  212-947-6507  -=-  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Juan Ingles)
Date: Wed, 11 May 1994 15:28:57 GMT
Organization: Proteus Ventures, Inc.

In article <2qkpv1$[e-mail]>
[e-mail] (Tim Smith) writes:

> It would only have to do this when you dropped an extension, control panel,
> or other magic file into a folder.  For most dropping, it doesn't matter
> if the destination is a System Folder, so it would not have to do more
> work in the vast majority of cases.
>
> --Tim Smith

Yes it would: It would have to check every single file to see if it was
an extension, control panel, or other magic file.

Juan Ingles
<[e-mail]>
--
Proteus Ventures, Inc. - Computer Software Consulting and Development
    1514 Oriole Ave * Waterloo, IA 50701 * [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Michael J. Bishop)
Date: 11 May 1994 18:00:02 GMT
Organization: University of Michigan

John F. Woods ([e-mail]) wrote:

: [e-mail] (Johan Solve) writes:
: >etaphors that needs to be explained (as the trashcan in the remove-disk
: <case) are not good metaphors. Picture a new user who has never seen a Mac
: >before. He inserts a disk and wants to get it out again. I don't think he
: <even dare to think of dragging it to the trash. There has to be a Mac guru
: >around to explain to him that "in this special case, nothing gets deleted.
: <But the disk will disappear from the desktop (and reappear on the real life
: >desktop...)"

: Let's remember how this came about.  Originally you ejected disks by selecting
: Eject from the menu (or typing command-E); this left a ghost image that had
: to be thrown away.  A lot of people asked for a short cut, and the obvious one
: was the one chosen.  Of course, if you don't KNOW what it's a shortcut for,
: it does seem to mean something else.

: On the other hand, if you had an Ejector on the desktop, what would it mean to
: drag an ordinary file onto it?


Here's what I think Apple should do. Let me know if you think it is good
or bad.

-- after I installed the Hardware system update on my powerbook, when I
hit the power button, it performed the same command as if I had selected
"Shut Down". It's the old "hardware/software integration" genius that
Apple is famous for.

Why don't they do this for the disk drive? Why don't they make a button
that when pushed performs the same command as if the user selected "Put
Away" from the File menu?

People expect there to be an eject button like on a PC. Putting a button
which triggers the software is the best compromise, I believe because it
still allows Apple to do that cool hardware integration stuff but is
still intuitive to the user.

I personally *hate* having to select Shut Down to turn of my mac so the
Hardware update was genius and much needed IMO.

--
_____________________________________________________________________________
 Michael Bishop     "The best way to predict the future is to invent it."
 [e-mail]                        - Alan Kay

+++++++++++++++++++++++++++

>From [e-mail] (Ron Hunsinger)
Date: Wed, 11 May 94 06:26:41 PST
Organization: Berkeley Macintosh Users Group

To: [e-mail] (Pete Resnick),UUCP

>In article <2qido4$[e-mail]>, [e-mail] (Jon Wdtte)
>wrote:
>
>>Exactly how would the Swedish Finder know about the names of the
>>Hindu special folders?
>
>The same way it knows what the names of the Swedish special folders are:
>
>    GetResource('fld#', 0);
>

Wouldn't work.  This would only tell the Swedish Finder the names of the
*Swedish* special folders.  Although...

If Apple was hard-pressed, I suppose the active Finder could look in
the boot blocks of the other System Folder's volume to get the name of
the other Finder, then open the other Finder's resource fork and get the
folder names from it.  And do all this only if the destination folder
matches the id of the blessed folder (available from vcbFndrInfo).  Might
actually be doable in reasonable time, because you would only have to open
the other Finder if you actually had files to disburse into special folders.

>pr
>--
>Pete Resnick    (...so what is a mojo, and why would one be rising?)

According to "The Official Scrabble Players Dictionary (Second Edition)":

    MOJO   n,  pl. -JOS or -JOES,  a magic charm.

I believe this is New Orleans slang, possibly of Cajun origin.

In any event, "Mr. Mojo Risin" is an anagram for "Jim Morrison".

Just so you'll know...
-Ron Hunsinger

+++++++++++++++++++++++++++

>From [e-mail] (ROBERT A. UHL )
Date: Wed, 11 May 1994 22:04:07 GMT
Organization: University of Denver

In article <2qarlc$[e-mail]> [e-mail] writes:
>[e-mail] (Rick Reynolds aka GreenGoo) writes:
>
>>>How 'bout dragging a disk to the trash to eject it?
>
>
>>I never really thought much about this issue but I think there should
>>have been a disk drive icon on the desktop, always visable but somehow
>>conveying to the user that a disk is inserted.
>
>Uh, what about the disk's icon? Granted, it can be hidden behind windows,
>but I'd rather have what *I* want to stay on top of the desktop layer
>rather than some floating icons or whatever.
>
>>When the user wants
>>to change disks they can press an "eject" button on the icon. But alas
>>that brings up the problem of having a control (which woule have to be
>>smaller then other controls) on a Finder icon.
>
>Now you're on to something. How about letting every icon that is a volume
>have a 'switch' or 'button' drawn on (or near) the icon that let's you
>eject the volume (eject in the sense of "Put Away"). It could even be dimmed
>out for volumes that can't be "Put Away", like the startup volume.
>--
>Alan A. DeGuzman

Here's another idea:
I've always thought that ejecting the disk should get rid of it; you
know, if it's out, I can put it in the box and forget about it. Also,
the 'Eject' button in the SF dialogs is not a true (IMO) eject;
nothing is more annoying to be flipping through floppies on the SF
dialog (which I do a lot) and, when you quit, finding a whole mess of
grey floppy icons.
So... I propose that 'Eject' take the place of the current 'Put Away',
and that the 'spit-out-the-disk-but-keep-it-mounted' action be
renamed. Not only would this be helpful in the above mentioned ways,
but command-E would truly eject the ?!*% disk.

--
- -------------------------------------------------------
| Bob Uhl | Spectre                  | Christos Anesti! |
| U of D  | Baron Robert von Raetzin | Alithos Anesti!  |
- -------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 12 May 94 17:14:12 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <2qido4$[e-mail]>, [e-mail] (Jon Wdtte) writes:
>
> Exactly how would the Swedish Finder know about the names of the
> Hindu special folders?

I guess the same way it would know about the Muslim special folders, or
the Christian special folders, or the Jewish ones, or the atheist ones. :-)

Lawrence
(born in a place long influenced by Indian culture)

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Thu, 12 May 1994 11:10:49 GMT
Organization: PRZ TU-Berlin

In article <[e-mail]> [e-mail] (ROBERT A. UHL ) writes:
>
>So... I propose that 'Eject' take the place of the current 'Put Away',
>and that the 'spit-out-the-disk-but-keep-it-mounted' action be
>renamed. Not only would this be helpful in the above mentioned ways,
>but command-E would truly eject the ?!*% disk.

No, no, no, no.

You need the 'spit-out-the-disk-but-keep-it-mounted' feature in order
to copy disks on Macs with only one floppy drive (which is surely
the vast majority of machines out there).

There is NOTHING to be gained by renaming menu commands in 1994. There
are people out there who have been happily dragging disks to the
trash for over ten years. To quote Tog: "An imporant aspect of
consistency was defined by Smith et al. [1983] in this way: 'Consistency
asserts that mechanisms should be used in the same way wherever they
occur.' I would add, by inference, 'and _when_ever they occur':
first release or fifth release." (from "Consistency", in The Art
of Human-Computer Interface Design, Addison-Wesley 1990, Tog's emphasis.)

We now have in the current system:

1) A menu command (w/ command-key equivalent) for ejecting a disk.
2) A menu command (w/ command-key equivalent) for ejecting AND unmounting
   a disk.
3) A simple mouse gesture for ejecting AND unmounting a disk.

I honestly can *NOT* understand all this bitching about (3) above. If
you don't want to drag the disk to the trash, then DON'T DO IT. Hit
Command-Y and shut up.

(BTW, despite my current .sig, this is one point where there is simply
nothing to be gained by negating the principle of consistency.)


--
Peter Castine                  | Con'sis'ten'cy (n., pl. -cies)
[e-mail]      | 1a) last refuge of the unimaginative
- -----------------------------| b) hobgoblin of little minds
   ``Have Mac, will travel''   | (Apologies to Webster, Emerson, & Wilde)

+++++++++++++++++++++++++++

>From [e-mail] (Greg Weston)
Date: 12 May 94 05:04:11 GMT
Organization: New Jersey Institute of Technology, Newark, New Jersey

In article <[e-mail]>,
Chuck Simciak <[e-mail]> wrote:
>I'm not sure if this counts as breaking an interface guideline but it is
>very annonying.  Say I go to save a file, the StandardPutFile dialog
>emerges and I have to navigate several folders to get to my desitination.
> The file name field has already been filled with a defualt.  Here's the
>catch.  Upon having navigated the multiple folders to place the file, the
>SAVE button is now an OPEN button.  I then have to click in the filename
>text field to cause the button to CHANGE to SAVE.  This "feature" was
>introduced in System 7 and has been a source of nuisance ever since.

I find it tedious, too. But it is a little easier (I find) to press
tab, which toggles between manipulating the list and the field, than
to grab the mouse and click. (Since in that situation, I've usually
had my hands on the keyboard up til then anyway.)
    Greg

+++++++++++++++++++++++++++

>From [e-mail] (MMMMM MMMMM)
Date: 12 May 1994 11:57:20 -0400
Organization: Georgia Institute of Technology

In article <[e-mail]> [e-mail] (Peter Castine) writes:
>In article <[e-mail]> [e-mail] (ROBERT A. UHL ) writes:
>I honestly can *NOT* understand all this bitching about (3) above. If
>you don't want to drag the disk to the trash, then DON'T DO IT. Hit
>Command-Y and shut up.
>

I think you're forgetting the original point of this thread.  Yes,
dragging a disk to the trash is quick, easy, and we all do it.  But it
does violate the Mac HIG.

It's unintuitive.  And I'm willing to admit that I was terrified the first
time I tried dragging a floppy to the trash.



--
  /////////\    /////////\    /////////\    /////////\    /////////\
  \_____// /   //\____// /   //\____// /   //\____// /   //\____// /
       ///////// /   ///////// /   ///////// /   ///////// /   /////////\
       \_______\/    \_______\/    \_______\/    \_______\/    \_______\/

+++++++++++++++++++++++++++

>From [e-mail] (Matt Mora)
Date: 12 May 1994 08:54:10 -0700
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] (Peter Castine) writes:

>No, no, no, no.
>
>You need the 'spit-out-the-disk-but-keep-it-mounted' feature in order
>to copy disks on Macs with only one floppy drive (which is surely
>the vast majority of machines out there).

nah, what we need to implement is Andy Herzfeld (sp?) velocity
feature. Pick up a disk icon with the mouse and throw it off the desktop
to eject it. :-) The disk icon would then glide across the desktop and when it
the icon was completly off the desktop, it would eject. Kind of like when
a disk falls off your desk.

If you didn't throw it hard enough it would glide to a halt some where on
your desktop.

Ejecting a disk should be fun!


Xavier

--
___________________________________________________________
Matthew Xavier Mora                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (Steve Baumgarten)
Date: 12 May 94 12:51:39
Organization: PANIX Public Access Unix, NYC

In article <2qtjl0$[e-mail]> [e-mail] (MMMMM MMMMM) writes:

   I think you're forgetting the original point of this thread.  Yes,
   dragging a disk to the trash is quick, easy, and we all do it.  But
   it does violate the Mac HIG.

No it doesn't.  It's a shortcut you don't have to use.  Try selecting
"Put Away" from the menu; or select "Eject", and then with the disk in
your hand you should have no fear of dragging the dimmed icon to the
trash.

   It's unintuitive.  And I'm willing to admit that I was terrified
   the first time I tried dragging a floppy to the trash.

Should have tried using the menus first; that's what they're there
for.

If it were the Mac's sole means of ejecting a floppy, then yes, I'd
agree that it's not intuitive.  But a menu choice labeled "Eject" is
pretty intuitive, you have to admit...

--
    Steve Baumgarten       |  "New York... when civilization falls apart,
    PANIX, New York, NY    |   remember, we were way ahead of you."
                           |
    Email: [e-mail]   |                            - David Letterman

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Thu, 12 May 1994 17:11:36 GMT
Organization: PRZ TU-Berlin

[e-mail] (MMMMM MMMMM) writes:
>
>[e-mail] (Peter Castine) writes:
>>I honestly can *NOT* understand all this bitching about (3) above. If
>>you don't want to drag the disk to the trash, then DON'T DO IT. Hit
>>Command-Y and shut up.
>>
>
>I think you're forgetting the original point of this thread.  Yes,
>dragging a disk to the trash is quick, easy, and we all do it.  But it
>does violate the Mac HIG.

No it doesn't. It's an extension of the Finder's interface.

Take a look at HIG p. 38 ('When to go beyond the guidelines'):

    There are times when the standard user interface doesn't cover the
    needs of your application. This is true in the following situations:

    o Your are creating a new feature for which no element or behavior
      exists. In this case, you can extend the Macintosh user interface
      in a prescribed way.

    o  An existing element does almost everything you need it to, but
       a little modification that improves its functions makes the
       difference to your application.

The drag-disk-to-trash convention is *built on an existing interface
convention.* (Cf. HIG p. 39) To repeat: the original method was to Eject
(or Command-E) the disk and drag the off-line icon to the trash.

>It's unintuitive.  And I'm willing to admit that I was terrified the first
>time I tried dragging a floppy to the trash.

Gee, I dunno. I seem to remember way back in spring of '84 wondering
"how do I get rid of this disk?", checking out the menus and finding
Eject. Sure, I was a little surprised when the shadow of the disk
stayed on the desk, but since there didn't seem to be any other
appropriate menu items, I dragged the outline to the trash. A day
or two later, I thought "Why not combine the two steps and drag the
disk straight to the trash? This is a Mac, before something aweful
happens, one of these funny message window thingies is sure to pop
up and let me back out." (How many people remember the funny alert
icons Apple used back then? Now, *those* were worth changing.)

Nowadays, I think a lot of beginners click on that funny question
mark thingie at the top right of the screen. Guess what Balloon
Help says about the trash?

BTW, the adjective should be 'unintuitable'. See _Tog on Interface_.
Sorry, I'm getting pedantic.

Admittedly, naive Mac users sometimes get nervous when they see me
dragging a disk to the trash. When this happens, I also go into
teacher mode, do the two-step Eject/Trash Outline procedure,
demonstrate the Put Away command, and then show the one-step
Trash shortcut. But I'd bet they hit on the idea in a couple
of weeks on their own.

Wonder which people work out faster--dragging a disk to the trash
or the 'xp' trick in vi?


--
Peter Castine                  | Con'sis'ten'cy (n., pl. -cies)
[e-mail]      | 1a) last refuge of the unimaginative
- -----------------------------| b) hobgoblin of little minds
   ``Have Mac, will travel''   | (Apologies to Webster, Emerson, & Wilde)

+++++++++++++++++++++++++++

>From Antoine Paul Brusseau <[e-mail]>
Date: Thu, 12 May 1994 16:34:49 -0400
Organization: Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.mac.programmer: 12-May-94 Re: Apple's
blatant disrega.. by Peter [e-mail]
> Take a look at HIG p. 38 ('When to go beyond the guidelines'):
>
>         There are times when the standard user interface doesn't cover the
>         needs of your application. This is true in the following situations:
>
>         o Your are creating a new feature for which no element or behavior
>           exists. In this case, you can extend the Macintosh user interface
>           in a prescribed way.
>
>         o  An existing element does almost everything you need it to, but
>            a little modification that improves its functions makes the
>            difference to your application.
>
>The drag-disk-to-trash convention is *built on an existing interface
>convention.* (Cf. HIG p. 39) To repeat: the original method was to Eject
>(or Command-E) the disk and drag the off-line icon to the trash.


    If Apple had added a close box to disk icons, people wouldn't be
declaring this a violation of HIG. The problem is, the trash icons most
common analogy is that of a place one puts items in order to
*PERMANENTLY DESTROY THEM*. Putting a disk in the trash, does not do
this. This violates peoples expectations. Thus, it is a poor UI design
decision. Whereas, a close box is used to remove an item from the
desktop. Putting a close box on disk icons would have built on an
existing interface convention without violating any preexisting ones (I
think:).

Tony

+++++++++++++++++++++++++++

>From Stephen Jonke <[e-mail]>
Date: 12 May 1994 22:09:24 GMT
Organization: NASA GSFC

Sorry if this is a repeat, but you can use "Put Away" (Command-Y) in the
"File" menu to unmount a disk.  I can't remember when this capabilit was
added to Put Away - some version of System 7 in any case.  This concept
is somewhat intuitive, except that "Eject Disk" seems like it should do
this and it draws the users attention.  My sister has been using Eject
Disk when she wants to just get the disk out and I can understand why as
this seems the intuitive thing to do.  Does anyone every use "Eject Disk"
in its current form intentionally any more?  Seems like the simple
solution is to change it's functionality so that it unmounts the disk
without leaving the ghost icon on the desktop, as one would expect.  Keep
the drag to trash alternative since lots of Mac users are use to that.
And then have it so that if you select a floppy disk and pick "Duplicate"
it does the floppy copying shennanigans.  Doesn't this make a heck of a
lot more sense?

Steve

- -------------------
 [e-mail]
- -------------------

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Fri, 13 May 1994 08:38:56 GMT
Organization: PRZ TU-Berlin

[e-mail] (Michael J. Bishop) writes:
>
>Here's what I think Apple should do. Let me know if you think it is good
>or bad.
>
>-- after I installed the Hardware system update on my powerbook, when I
>hit the power button, it performed the same command as if I had selected
>"Shut Down". It's the old "hardware/software integration" genius that
>Apple is famous for.
>
>Why don't they do this for the disk drive? Why don't they make a button
>that when pushed performs the same command as if the user selected "Put
>Away" from the File menu?
>
>People expect there to be an eject button like on a PC. Putting a button
>which triggers the software is the best compromise, I believe because it
>still allows Apple to do that cool hardware integration stuff but is
>still intuitive to the user.

There is a question of cost.

Anyone care to estimate what that would add to the price of a Mac?
A simple mechanical switch isn't going to do the trick, you need
something that will send a signal to the logic board, etc.

And don't forget that adding, say $5, to manufacturing costs means
a three digit price increse for the consumer.

Still, it's not a bad idea. But see my next comment.

>I personally *hate* having to select Shut Down to turn of my mac so the
>Hardware update was genius and much needed IMO.

Using the power switch as a shortcut for Shut Down makes sense on a
PowerBook for two reasons: 1) the switch already has the necessary
connections to the logic board (you couldn't do this on an SE, where
the power switch simply cuts of the power supply) and 2) you can
normally reach the switch on a PB without any inconvenience. Many
Quadra and Mac II boxes are stuck under a desk (and with them the
diskette drives)--in this configuration, menu commands are considerably
more convenient. And, although I use the PowerKey extension so I
can drop into MacsBugs from the keyboard, I don't really want to
have the Shut Down command anywhere on my keyboard--too easy
to hit by accident (of course, some people *do* map some key
combinations to the Shut Down command... and one of them wrote
an extension so that Shut Down produces an Alert "Do you really
want to shut down now?" because he hit the key combination by
accident too often. This is progress :-? )

I'm not sure if it's possible for an extension to catch the signal
sent by the power switch on the Mac II family and cause it to
initiate the Shut Down sequence. Now that the subject has been on
the net, I expect somebody will try. ;-)

--
Peter Castine                  | Con'sis'ten'cy (n., pl. -cies)
[e-mail]      | 1a) last refuge of the unimaginative
- -----------------------------| b) hobgoblin of little minds
   ``Have Mac, will travel''   | (Apologies to Webster, Emerson, & Wilde)

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Fri, 13 May 1994 09:07:26 GMT
Organization: PRZ TU-Berlin

Antoine Paul Brusseau <[e-mail]> writes:
>
>    If Apple had added a close box to disk icons, people wouldn't be
>declaring this a violation of HIG. The problem is, the trash icons most
>common analogy is that of a place one puts items in order to
>*PERMANENTLY DESTROY THEM*.

*NO IT DOES NOT*. Drag some files to the trash. See the trash can
get fat. Open the trash. There are your files. Select a file. Use
the Put Away command. Hey, presto-the file is back where it came
from. Drag another file onto the desktop. There it is--this is
not permanent destruction.

This is a Mac, not an Atari.

Selecting "Empty Trash" permanently destroys the file (well, for
most users it's close enough to destruction). You also get
an alert warning you of this (just like HIG advises).

> Putting a disk in the trash, does not do
>this. This violates peoples expectations. Thus, it is a poor UI design
>decision. Whereas, a close box is used to remove an item from the
>desktop. Putting a close box on disk icons would have built on an
>existing interface convention without violating any preexisting ones (I
>think:).

A disk icon is a fairly small object. 32x32 pixels. A close box is also
a small object. 10x10 pixels. That's 10% of a disk icon. 10% is actually
a lot (particularly nowadays, with custom disk icons that have rockets
shooting out of them).

[As a footnote, Fitt's law would indicate that it takes about three
times as long to move the mouse to a close box as it does to move
the mouse to grab a disk icon for dragging. Someone want to do
a comparison of these two alternatives for un-mounting a disk
a la Card et.al.'s _The Psychology of Human-Computer Interaction_?]

I'm not saying that the suggestion to add a close box is a bad one.
However, I think it needs to be thought through more thoroughly.

--
Peter Castine                  | Con'sis'ten'cy (n., pl. -cies)
[e-mail]      | 1a) last refuge of the unimaginative
- -----------------------------| b) hobgoblin of little minds
   ``Have Mac, will travel''   | (Apologies to Webster, Emerson, & Wilde)

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Fri, 13 May 1994 09:28:02 GMT
Organization: PRZ TU-Berlin

Stephen Jonke <[e-mail]> writes:
>Sorry if this is a repeat, but you can use "Put Away" (Command-Y) in the
>"File" menu to unmount a disk.  I can't remember when this capabilit was
>added to Put Away - some version of System 7 in any case.

7.0d1, if I'm not mistaken. As far as users are concerned, since day
1 A.S. (anno septimum, or whatever the Latin would be :)

> This concept
>is somewhat intuitive, except that "Eject Disk" seems like it should do
>this and it draws the users attention.  My sister has been using Eject
>Disk when she wants to just get the disk out and I can understand why as
>this seems the intuitive thing to do.  Does anyone every use "Eject Disk"
>in its current form intentionally any more?

Yes!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Constantly.

> Seems like the simple
>solution is to change it's functionality

No.

Changing functionality of commands between software versions
is one of the worst possible violations of human interface design
concievable. Think about it--what would happen if Ford swapped the
position of the emergency brake and the gear shift. Or, if you're
using automatic transmission, how about swapping the gas pedal
and the brake. Think about it--do you really want to have to check
the system software version every time you sit down at a new Mac
so that you know which command configuration you've got?

>so that it unmounts the disk
>without leaving the ghost icon on the desktop, as one would expect.  Keep
>the drag to trash alternative since lots of Mac users are use to that.
>And then have it so that if you select a floppy disk and pick "Duplicate"
>it does the floppy copying shennanigans.  Doesn't this make a heck of a
>lot more sense?a

System 8 might extend Duplicate to copying disks. I rather expect not,
since the current trend in the interface is towards enhanced use of
mouse gestures (there will be less Cut/COpy/Paste as drag-and-drop
is implemented in more and more applications). In fact, the mouse
gesture for copying disks was one of the earliest implementations
of drag-and-drop on Macintosh.

--
Peter Castine                  | Con'sis'ten'cy (n., pl. -cies)
[e-mail]      | 1a) last refuge of the unimaginative
- -----------------------------| b) hobgoblin of little minds
   ``Have Mac, will travel''   | (Apologies to Webster, Emerson, & Wilde)

+++++++++++++++++++++++++++

>From [e-mail] (David Gillies)
Date: Fri, 13 May 1994 12:25:46 GMT
Organization: Unseen University, Ankh-Morpork

In article <[e-mail]> [e-mail] (ROBERT A. UHL ) writes:
>Here's another idea:
>I've always thought that ejecting the disk should get rid of it; you
>know, if it's out, I can put it in the box and forget about it. Also,
>the 'Eject' button in the SF dialogs is not a true (IMO) eject;
>nothing is more annoying to be flipping through floppies on the SF
>dialog (which I do a lot) and, when you quit, finding a whole mess of
>grey floppy icons.
>So... I propose that 'Eject' take the place of the current 'Put Away',
>and that the 'spit-out-the-disk-but-keep-it-mounted' action be
>renamed. Not only would this be helpful in the above mentioned ways,
>but command-E would truly eject the ?!*% disk.
>
Of course 'Eject' ejects the disk. It enables you to remove it from the disk
drive, doesn't it? That fits any reasonable definiton of eject in my book.
It takes most people with an IQ higher than that of a potato to realise
the difference between 'Eject', and 'Put Away'. For those amongst us who are
not completely illiterate, the distinction is also pointed out in *the manual*
(you know, that big thick ring-bound thing that is put on one side by MacBozos
and never read, thereby generating 98% of tech support traffic, and giving
rise to those 'Tricks'n'Tips' columns in magazines, full of things like "did
you know that if you hold down the option key when opening a folder, the
parent folder will disappear?")

Changing the way this works now would only serve to confuse the people who
extracted their heads from their arses long enough to actually understand
how to use a Mac.

Keeping volumes mounted is a time-saving feature. If you had to wait the
twenty seconds or so it takes to mount a floppy every time you popped one out
of the slot in the Standard File dialog, you'd go mad. It's not perfect, but
until someone comes up with abetter solution we're stuck with it.

______________________________________________________________________
David A. G. Gillies                     ([e-mail])
      University of Bradford, Bradford, West Yorkshire, England
(c) 1994 Wittgenstein and The Furniture Depository of The Living Dead

A little learning is a dangerous thing - but not half as dangerous as a
lot of ignorance.
- ---------------------REPLIES VIA EMAIL PLEASE-----------------------
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

+++++++++++++++++++++++++++

>From [e-mail] (David Gillies)
Date: Fri, 13 May 1994 12:30:48 GMT
Organization: Unseen University, Ankh-Morpork

In article <2qtjf2$[e-mail]> [e-mail] (Matt Mora) writes:
>In article <[e-mail]> [e-mail] (Peter Castine) writes:
>
>>No, no, no, no.
>>
>>You need the 'spit-out-the-disk-but-keep-it-mounted' feature in order
>>to copy disks on Macs with only one floppy drive (which is surely
>>the vast majority of machines out there).
>
>nah, what we need to implement is Andy Herzfeld (sp?) velocity
>feature. Pick up a disk icon with the mouse and throw it off the desktop
>to eject it. :-) The disk icon would then glide across the desktop and when it
>the icon was completly off the desktop, it would eject. Kind of like when
>a disk falls off your desk.
>
>If you didn't throw it hard enough it would glide to a halt some where on
>your desktop.
>
>Ejecting a disk should be fun!
>
Great idea! Anyone want to write this? It could be a bit tricky...

______________________________________________________
David A. G. Gillies     ([e-mail])
(c) 1994 Wittgenstein's Amazing Underwater Supermarket
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

+++++++++++++++++++++++++++

>From Antoine Paul Brusseau <[e-mail]>
Date: Fri, 13 May 1994 09:30:06 -0400
Organization: Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.mac.programmer: 13-May-94 Re: Apple's
blatant disrega.. by Peter [e-mail]
> >    If Apple had added a close box to disk icons, people wouldn't be
> >declaring this a violation of HIG. The problem is, the trash icons most
> >common analogy is that of a place one puts items in order to
> >*PERMANENTLY DESTROY THEM*.
>
> *NO IT DOES NOT*. Drag some files to the trash. See the trash can
> get fat. Open the trash. There are your files. Select a file. Use
> the Put Away command. Hey, presto-the file is back where it came
> from. Drag another file onto the desktop. There it is--this is
> not permanent destruction.

I think you misread my post. I said "in order to *PERMANENTLY DESTOY
THEM*", not "so that they are *IMMEDIATELY DESTROYED*". To further the
analogy, if I put an object from my desk into the rubish bin, it is not
immediately destroyed. If I choose, I can take the object out any time
before the cleaning staff comes. This is the correct analogy, and it is
followed consistently with file icons. Putting a floppy disk into the
trash in order to eject it does not follow this analogy. This is the
point of my previous post.

Tony

+++++++++++++++++++++++++++

>From [e-mail] (Tom Dowdy)
Date: Fri, 13 May 1994 15:40:32 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail]
(Charles Wiltgen) wrote:
> In article <[e-mail]>,
> [e-mail] (John V. Blzka) wrote:
>
> > Hello,
> > I've been working on a presentation on Human Factors Engineering.
> > I am using Apple's User Interface Guidelines as an example.
> > What I would like to know is:
> >   Does Apple violate it's own Guidelines in any of it's System 7
> >   software?
> >   If so, can I easily demonstrate it?
>
> How 'bout dragging a disk to the trash to eject it?

I'm not sure how this is a direct violation of the UI guidelines
(and maybe it is)...It *is* probably a non-intuative feature,
that wasn't well thought out for first implementation.

However, I'd like to ask you if you now use the "Put Away" menu
item in System 7, which performs the same function.  Or, do
you continue to drag the disk to the trash.  If you continue
to drag the disk to the trash -- why?  If we took away
that feature, would you complain?

--
 Tom Dowdy                  Internet: [e-mail]
 Apple Computer MS:302-3KS  UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy
 1 Infinite Loop            AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

+++++++++++++++++++++++++++

>From [e-mail] (Michael J. Bishop)
Date: 13 May 1994 16:28:51 GMT
Organization: University of Michigan

Peter Castine ([e-mail]) wrote:
: [e-mail] (Michael J. Bishop) writes:

: Anyone care to estimate what that would add to the price of a Mac?
: A simple mechanical switch isn't going to do the trick, you need
: something that will send a signal to the logic board, etc.

: And don't forget that adding, say $5, to manufacturing costs means
: a three digit price increse for the consumer.

: Still, it's not a bad idea. But see my next comment.

: >I personally *hate* having to select Shut Down to turn of my mac so the
: >Hardware update was genius and much needed IMO.

: Using the power switch as a shortcut for Shut Down makes sense on a
: PowerBook for two reasons: 1) the switch already has the necessary
: connections to the logic board (you couldn't do this on an SE, where
: the power switch simply cuts of the power supply) and 2) you can
: normally reach the switch on a PB without any inconvenience. Many
: Quadra and Mac II boxes are stuck under a desk (and with them the
: diskette drives)--in this configuration, menu commands are considerably
: more convenient. And, although I use the PowerKey extension so I
: can drop into MacsBugs from the keyboard, I don't really want to
: have the Shut Down command anywhere on my keyboard--too easy
: to hit by accident (of course, some people *do* map some key
: combinations to the Shut Down command... and one of them wrote
: an extension so that Shut Down produces an Alert "Do you really
: want to shut down now?" because he hit the key combination by
: accident too often. This is progress :-? )

Ah ha! I can build on that. The ergonomic keyboard comes with an
extension which allows the keyboard to switch the volume up and down. How
hard would it be to use one of those "new" keys to eject the disk? Then
both the power key and the "put away" key are both accessible from the
keyboard. Apple adds new keys all the time that do cool new things. I
think they could have added a "put away" key.

: --
: Peter Castine                  | Con'sis'ten'cy (n., pl. -cies)
: [e-mail]      | 1a) last refuge of the unimaginative
: -------------------------------| b) hobgoblin of little minds
:    ``Have Mac, will travel''   | (Apologies to Webster, Emerson, & Wilde)

--
_____________________________________________________________________________
 Michael Bishop     "The best way to predict the future is to invent it."
 [e-mail]                        - Alan Kay

+++++++++++++++++++++++++++

>From [e-mail] (Mel Walker)
Date: Fri, 13 May 1994 16:37:17 GMT
Organization: Committee to Elect Dan Quayle Lord of the Cosmos

Antoine Paul Brusseau ([e-mail]) wrote:
:     If Apple had added a close box to disk icons, people wouldn't be
: declaring this a violation of HIG. The problem is, the trash icons most
: common analogy is that of a place one puts items in order to
: *PERMANENTLY DESTROY THEM*.

No, the common analogy is that one puts items into a trash can in order
to *GET RID OF THEM*. Thus, when I want to get rid of a disk, I throw it
in the trash. I does not violate my expectations in the slightest.

: Putting a disk in the trash, does not do
: this. This violates peoples expectations. Thus, it is a poor UI design
: decision. Whereas, a close box is used to remove an item from the
: desktop. Putting a close box on disk icons would have built on an
: existing interface convention without violating any preexisting ones (I
: think:).

What happens when you double-click on the disk to open it, and hit the
close box? Since the close box would take a sizeable amount of the disk
icon, I figure that it would happen quite a bit. In addition, the close
box would interfere with my cool custom icons. :-)

Just out of curiousity, are there any GUIs that put close boxes on a disk
icon?
--
Mel Walker                                     [e-mail]

+++++++++++++++++++++++++++

>From Stephen Jonke <[e-mail]>
Date: 13 May 1994 17:47:43 GMT
Organization: NASA GSFC

In article <[e-mail]> Peter Castine,
[e-mail] writes:
>Changing functionality of commands between software versions
>is one of the worst possible violations of human interface design
>concievable. Think about it--what would happen if Ford swapped the
>position of the emergency brake and the gear shift. Or, if you're
>using automatic transmission, how about swapping the gas pedal
>and the brake.

I disagree with this opinion.  You can't compare these two things,
because the consequences are quite drastically different.  If you do what
you suggest with cars, people can be killed.  If you do what I suggest
with Empty Trash and duplicate, you risk people being annoyed once or
twice, then seeing that it's better and being happy with it.  That's not
much of risk and there is great reward.  If lots of people use the
current Eject Disk functionality for things other then copying, then they
could throw in a new command that does this (offhand I can't think of a
name) that is NOT "Eject Disk".

You can go overboard with consistency and this is a perfect example.  You
are being consistent with something that was wrong to start with.  That
is a greater mistake, IMHO.  Plus, Apple's goal these days is to attract
NEW Mac users and if there are quirks like the Eject Disk "feature", they
are going to pick these out and say "boy, this is stupid, I'm going back
to my PC which is just as good" (not that this is true, but we are
talking about PC users who are confinced their PCs are just as good!  :)

Actually, here's another alternative that would be a better, but not as
good as my first suggestion.  Keep Eject Disk and have it appear to do
the same as usual, but make it so that it no longer asks you to put the
disk in if you shutdown (or whatever.)  Also, you should be able to drag
the greyed disk icon to the trash similarly.  This is actually the way it
use to work anyway, right?

Steve

- -------------------
 [e-mail]
- -------------------

+++++++++++++++++++++++++++

>From David Casseres <[e-mail]>
Date: Fri, 13 May 1994 17:46:08 GMT
Organization: Apple Computer, Inc.

In article <dowdy-130594083624@17.202.72.12> Tom Dowdy, [e-mail] writes:
> I'm not sure how this is a direct violation of the UI guidelines
> (and maybe it is)...It *is* probably a non-intuative feature,
> that wasn't well thought out for first implementation.
>
> However, I'd like to ask you if you now use the "Put Away" menu
> item in System 7, which performs the same function.  Or, do
> you continue to drag the disk to the trash.  If you continue
> to drag the disk to the trash -- why?  If we took away
> that feature, would you complain?

I bet anything that if we took away that feature there would be howls of rage
from so many people that we'd put it right back in as quickly as possible.

I was around when this was invented, and I guarantee that everyone knew it was
unintuitive, and thought hard about it.  But everyone also knew that there
really had to be a way to eject a diskette with just a simple mouse gesture,
and no one could come up with a better way to do it.

There are lots of things about GUI design that simply can't be accounted for
in guidelines.  For example, when you drag a file from one folder to another,
it disappears from its original location and appears in the new location.

*Except*... if you are dragging it from one disk to another then it doesn't
disappear from the original location.  It's completely inconsistent and not
even intuitive, but it's *right*.

We know this because on the Lisa it worked the other way, and the file was
erased from its original disk after being copied to the new one.  And this
turned out to be *wrong*, even though it was consistent and intuitive.

Sometimes even the best guidelines need to be blatantly disregarded.

- -----------

David Casseres
Exclaimer: Hey!

+++++++++++++++++++++++++++

>From [e-mail] (Pete Resnick)
Date: 13 May 1994 18:44:39 GMT
Organization: University of Illinois at Urbana

[e-mail] (Ron Hunsinger) writes:

>[e-mail] (Pete Resnick) writes:

>>In article <2qido4$[e-mail]>, [e-mail] (Jon Wdtte)
>>wrote:
>>
>>>Exactly how would the Swedish Finder know about the names of the
>>>Hindu special folders?
>>
>>The same way it knows what the names of the Swedish special folders are:
>>
>>    GetResource('fld#', 0);
>>

>Wouldn't work.  This would only tell the Swedish Finder the names of the
>*Swedish* special folders.  Although...

>If Apple was hard-pressed, I suppose the active Finder could look in
>the boot blocks of the other System Folder's volume to get the name of
>the other Finder, then open the other Finder's resource fork and get the
>folder names from it.  And do all this only if the destination folder
>matches the id of the blessed folder (available from vcbFndrInfo).

I think you are getting confused here. The question is, if I drag to a
non-blessed system folder, why can't the Finder figure out where to
put the files? To realize it's a legitamate (albeit unblessed) system
folder in the first place, you must *already* notice that there is a
System and a Finder in that folder. You don't need to go looking in
boot blocks to figure that out; you simply need to look at file types.
Once you discover that there are appropriate System and Finder files
using the file types, you can then open the appropriate one (I forget
whether the fld# is in the System or the Finder; I believe it's the
former) and do the GetResource from that file (I guess using
Get1Resource instead of GetResource actually). You won't get the ones
from the Swedish system since the Hindu (or whatever) system is the
current resource file. It doesn't have to be the blessed folder since
any system folder will be reasonable to put things into appropriate
places.

Right?

pr
--
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Michael Peirce)
Date: 13 May 94 00:44:48 GMT
Organization: Peirce Software, Inc.


In article <[e-mail]> (comp.sys.mac.advocacy,comp.sys.mac.programmer), [e-mail] (Zig Zichterman) writes:
> One place Apple violates its suggested guidelines in in the Finder's
> "About This Macintosh..." menu item. The Mac HI Guidelines book (pages 67-70)
> suggests that the ellipsis (...) should appear only on menu items that
> require *additional* information before they can complete (such as
> choosing a file from an Open... dialog, or setting up options in a
> Preferences... dialog, and so on). For menu items that execute without
> further information from the user, such as Cut, Copy, showing an About
> box, and so on, the ellipsis should not appear.
>
> After 10 years of tradition, who's going to really remove the ellipsis
> from their "About..." menu?

I've always interpretted the presence of an ellipsis to mean a dialog
will be called up, i.e. something will interupt you focus on the current
window.  Or more specifically, you'll have to do something to get
back to where you were.

With this interpretation, the About... is correct.

__ Michael Peirce        __ [e-mail]
__ Peirce Software, Inc. __ 719 Hibiscus Place, Suite 301
__                       __ San Jose, California USA 95117-1844
__ Makers of: Smoothie & __ voice: +1.408.244.6554 fax: [phone]
__    Peirce Print Tools __ AppleLink: peirce & AOL: AFC Peirce

+++++++++++++++++++++++++++

>From Antoine Paul Brusseau <[e-mail]>
Date: Fri, 13 May 1994 15:42:40 -0400
Organization: Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.mac.programmer: 13-May-94 Re: Apple's
blatant disrega.. by Mel [e-mail]
> No, the common analogy is that one puts items into a trash can in order
> to *GET RID OF THEM*. Thus, when I want to get rid of a disk, I throw it
> in the trash. I does not violate my expectations in the slightest.

Unfortunately, the most common consequence of getting rid of something
is that it is permanently destroyed (i.e., the trash icon is most often
used to destroy files). Thus, the association in many peoples' minds is
a place where one puts an item in order to permanently destroy it. The
reason I bring this up, is that more than a few people that I've taught
to use Apple computers have been shocked that putting a disk in the
trash can is the easiest way of ejecting a disk. Several non-technically
oriented people I know actively balk at using this feature because they
are afraid their data is going to be erased (no matter how many times I
reassure them it isn't). Philosophically and empirically, the evidence
indicates that this feature is more than a little dubious as a UI
shortcut.

Since many people including myself make extended use of this feature, it
is obviously desirible to have a UI shortcut for ejecting a disk (menus
are just too incovenient and command-y is too arcane). That's why I
think some other method (that doesn't violate common expectations), such
as having a close button on ejectable media volumes or dragging
ejectable media icons off the desktop, as a way of ejecting them is
preferable.

Tony

+++++++++++++++++++++++++++

>From Antoine Paul Brusseau <[e-mail]>
Date: Fri, 13 May 1994 15:55:08 -0400
Organization: Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.mac.programmer: 13-May-94 Re: Apple's
blatant disrega.. by David [e-mail]
> Sometimes even the best guidelines need to be blatantly disregarded.

That's by far the best argument I've heard in support of dragging icons
into the trash. But what about putting a close box on (or near) floppy
icons, or dragging them off the desktop in order to eject them? Both of
these methods sound intuitive and consistent (at least superficially).

Tony

+++++++++++++++++++++++++++

>From [e-mail]
Date: 14 May 94 04:04:01 MST
Organization: (none)

In article <Uhod=[e-mail]>, Antoine Paul Brusseau <[e-mail]> writes:
>     If Apple had added a close box to disk icons, people wouldn't be
> declaring this a violation of HIG. The problem is, the trash icons most
> common analogy is that of a place one puts items in order to
> *PERMANENTLY DESTROY THEM*. Putting a disk in the trash, does not do
> this. This violates peoples expectations. Thus, it is a poor UI design
> decision. Whereas, a close box is used to remove an item from the
> desktop. Putting a close box on disk icons would have built on an
> existing interface convention without violating any preexisting ones (I
> think:).
>
> Tony


Now figger out how to make sure that the close box was clicked on and the user
wasn't trying to either select or open the file...


Lawson

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Sat, 14 May 1994 10:31:04 GMT
Organization: PRZ TU-Berlin

Antoine Paul Brusseau <[e-mail]> writes:
>...more than a few people that I've taught
>to use Apple computers have been shocked that putting a disk in the
>trash can is the easiest way of ejecting a disk. Several non-technically
>oriented people I know actively balk at using this feature because they
>are afraid their data is going to be erased (no matter how many times I
>reassure them it isn't).

So, what do the people do instaed of dragging the disk to the trash?
Before System 7.0, the alternative was to Eject and then trash the
shadow. Did users back then (or the 40% of machines still running
System <7) keep on doing this? Or did they get used to the idea of
the shortcut? (Anybody have any data on this? Experience? Anecdotes?)

Do new users running System 7.x still keep to the Put Away command
(or the keyboard equivalent)? Or do they find the mouse gesture more
convenient?

When I've done Mac training (this is, admittedly, a while ago), I always
demonstrated the two-step method first, which seemed not to bother
people (except that it took two steps). *THEN* I showed the disk-to-trash
shortcut. SOme people like it. Some people get used to it. Others don't.

HIG lists no less than five different flavors of consistency. Only
one of these is consistency with people's expectations. Meeting the
expectations of ALL users is impossible (HIG is coy on this one, and
just says "it's difficult to meet the expectations of everyone."
It ain't difficult. It's 'mpossible.)

Take the following example:

I've trained people who expected the backspace key to work
like the left arrow (move the I-beam cursor to the left
in text editing without deleting characters). Why? Because that's
the way most typewriters work.

How about this: Teach people who've never worked with a computer
before how to use a spreadsheet. They will invariably
type 'x' instead of '*' for multiplication.

Sorry for the continuing sermon. I really just wanted to know
how long it takes people to become comfortable with the disk-
to-trash shortcut. I suspect that (with the exception of
those who have been forced to work with a Mac and are determined
to hate any aspect of it they can), the time is resonably short.
--
Peter Castine                  | Con'sis'ten'cy (n., pl. -cies)
[e-mail]      | 1a) last refuge of the unimaginative
- -----------------------------| b) hobgoblin of little minds
   ``Have Mac, will travel''   | (Apologies to Webster, Emerson, & Wilde)

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Sat, 14 May 1994 10:39:02 GMT
Organization: PRZ TU-Berlin

>Excerpts from netnews.comp.sys.mac.programmer: 13-May-94 Re: Apple's
>blatant disrega.. by David [e-mail]
>> Sometimes even the best guidelines need to be blatantly disregarded.
                                                 ~~~~~~~~~

No. The guidelines (all eleven of 'em, as well as a few other unstated
concerns such as efficiency and convenience for the user, as well as cost
and time for the developers) have to be balanced with one another.


--
Peter Castine                  | Con'sis'ten'cy (n., pl. -cies)
[e-mail]      | 1a) last refuge of the unimaginative
- -----------------------------| b) hobgoblin of little minds
   ``Have Mac, will travel''   | (Apologies to Webster, Emerson, & Wilde)

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Templeton)
Date: Sat, 14 May 1994 13:51:42 -0800
Organization: Stanford University

In article <[e-mail]>,
[e-mail] (Peter Castine) wrote:
> So, what do the people do instaed of dragging the disk to the trash?
> Before System 7.0, the alternative was to Eject and then trash the
> shadow. Did users back then (or the 40% of machines still running
> System <7) keep on doing this? Or did they get used to the idea of
> the shortcut? (Anybody have any data on this? Experience? Anecdotes?)
<deleted>
> Sorry for the continuing sermon. I really just wanted to know
> how long it takes people to become comfortable with the disk-
> to-trash shortcut. I suspect that (with the exception of
> those who have been forced to work with a Mac and are determined
> to hate any aspect of it they can), the time is resonably short.

I'm embarassed to admit, I had my Mac Plus for *two years* before I
realized that you could get rid of the ghost disk by dragging it to
the trash.  I just sat there and swapped disks until it let me go.
When I got too many ghost disks on my desktop, I restarted my computer.
Note that I was a very novice user, and did not know anyone else who
had a Macintosh.  I was very jealous of my friends who had eject
buttons on their PC's.

When I got to college, someone dragged my disk with a paper on it to
the trash and I almost had a heart attack.

As far as shortcuts go, Apple actually removed the one I really liked
with the introduction of System 7.  You could type Command-Option-E
and hold the option key down until the disk ejected and the ghost
would disappear.  With the Put Away command, you have to select the
disk with the mouse before it works.

Yup, Apple screwed up ejecting pretty bad.

-Bruce

--
|*Bruce Templeton                                      ______________ *|
|*[e-mail]                 DFOTB  /______________/|*|
|*Disclaimer:  The statements above reflect the      |  o   o   o  | |*|
|*opinions of virtually everyone I have ever met.    |_____________|/ *|

+++++++++++++++++++++++++++

>From [e-mail] (David Phillip Oster)
Date: Sat, 14 May 1994 23:02:06 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)


After all these years, surely the finder could have a little more Undo for

+++++++++++++++++++++++++++

>From [e-mail] (Tim Smith)
Date: 14 May 1994 05:39:07 GMT
Organization: University of Washington School of Law, Class of '95

Speaking of how manipulating things on the screen should be fun, surely I'm
not the only one who wants to be able to move the cursor by having commands
for "rotate left", "rotate right", and "thrust", am I?

--Tim Smith

+++++++++++++++++++++++++++

>From [e-mail] (Shimpei Yamashita)
Date: 15 May 1994 09:32:28 GMT
Organization: Stanford University, CA 94305, USA

In article <[e-mail]>,
David Gillies <[e-mail]> wrote:
:Of course 'Eject' ejects the disk. It enables you to remove it from the disk
:drive, doesn't it? That fits any reasonable definiton of eject in my book.
:It takes most people with an IQ higher than that of a potato to realise
:the difference between 'Eject', and 'Put Away'. For those amongst us who are
:not completely illiterate, the distinction is also pointed out in *the manual*

I've been using System 6 on a Plus since 1988. I saw System 7 for the first
time when I came to college, and I freely admit that it took me about
six months to realize that "Put Away" is the menu equivalent of dragging
the disk to the trash. It *is* counterintuitive that "ejecting the disk"
and "restoring files to their original folders" fall under the same command,
IMHO. And no, I could not have read the manual since they don't have
System 7 manuals lying around in the computer clusters....


--
Shimpei Yamashita, Stanford University           [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Stefan Kurth)
Date: 9 May 1994 02:13:04 +0200
Organization: Contributed Software GbR

Speaking of arrow keys in lists: what would be the correct behaviour when
the user types down-arrow, but nothing is currently selected? Should the
topmost or the bottom-most item be selected? The standard file package
behaves different from finder windows in this regard, which is a really
annoying inconsistency, if you ask me.

_____________________________________________________________________
Stefan Kurth              Berlin, Germany              [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Greg Landweber)
Date: 15 May 1994 21:41:25 GMT
Organization: (none)

In article <2qjv6g$[e-mail]> [e-mail] (Stefan Kurth) writes:
   Speaking of arrow keys in lists: what would be the correct behaviour when
   the user types down-arrow, but nothing is currently selected? Should the
   topmost or the bottom-most item be selected? The standard file package
   behaves different from finder windows in this regard, which is a really
   annoying inconsistency, if you ask me.

I'm not 100% sure, but I think that in such a situation the arrow keys
do nothing.  I'm using the ArrowKeyInList routine straight out of More
Macintosh Toolbox, and it returns empty handed when passed a list with
no current selection.  Of course, the sample code and the
documentation may not agree (and I seem to recall that the sample code
had a few bugs).

-- Greg
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Mon, 16 May 1994 16:41:52 +1200 (NZST)
Organization: (none)

[e-mail] (Tom Dowdy) writes:
> However, I'd like to ask you if you now use the "Put Away" menu
> item in System 7, which performs the same function.  Or, do
> you continue to drag the disk to the trash.

I can't remember the last time I dragged a disk to the trash.  It's
always <apple>-Y for me.

+++++++++++++++++++++++++++

>From [e-mail] (ROBERT A. UHL )
Date: Mon, 16 May 1994 17:24:43 GMT
Organization: University of Denver

In article <2qtjl0$[e-mail]> [e-mail] (MMMMM MMMMM) writes:
>In article <[e-mail]> [e-mail] (Peter Castine) writes:
>>In article <[e-mail]> [e-mail] (ROBERT A. UHL ) writes:
>>I honestly can *NOT* understand all this bitching about (3) above. If
>>you don't want to drag the disk to the trash, then DON'T DO IT. Hit
>>Command-Y and shut up.
>>
I'd like to say that the above quote belongs to Peter castine, not me;
the poster misquoted. The quote is not at all my style.
--
- -------------------------------------------------------
| Bob Uhl | Spectre                  | Christos Anesti! |
| U of D  | Baron Robert von Raetzin | Alithos Anesti!  |
- -------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Tue, 17 May 1994 18:14:49 +1200 (NZST)
Organization: (none)

[e-mail] (Stefan Kurth) writes:
> Speaking of arrow keys in lists: what would be the correct behaviour when
> the user types down-arrow, but nothing is currently selected? Should the
> topmost or the bottom-most item be selected? The standard file package
> behaves different from finder windows in this regard, which is a really
> annoying inconsistency, if you ask me.

It annoys me too.  I much prefer getting the topmost item in this situation,
and that's how I write my own programs.

I think Finder windows are the *only* place it happens the other way around,
and it's stupid.

Think how you select the third (say) item in a list.  In the Finder you need
to hit the up arrow once, then down twice.  Anywhere else you just hit down
three times (or hold the key down for items further down the list).

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (Jeff Croft)
Date: 17 May 1994 01:31:02 -0600
Organization: University Of Utah Computer Center

David Gillies ([e-mail]) wrote:

: Keeping volumes mounted is a time-saving feature. If you had to wait the
: twenty seconds or so it takes to mount a floppy every time you popped one out
: of the slot in the Standard File dialog, you'd go mad. It's not perfect, but
: until someone comes up with abetter solution we're stuck with it.

Gee. It's too bad that it takes that long to mount a floppy.

                 Jeff


+++++++++++++++++++++++++++

>From [e-mail] (Ron Hunsinger)
Date: Tue, 17 May 94 06:50:16 PST
Organization: Berkeley Macintosh Users Group

[e-mail] (Pete Resnick) writes:

>[e-mail] (Ron Hunsinger) writes:
>
>>If Apple was hard-pressed, I suppose the active Finder could look in
>>the boot blocks of the other System Folder's volume to get the name of
>>the other Finder, then open the other Finder's resource fork and get the
>>folder names from it.  And do all this only if the destination folder
>>matches the id of the blessed folder (available from vcbFndrInfo).
>
>I think you are getting confused here. The question is, if I drag to a
>non-blessed system folder, why can't the Finder figure out where to
>put the files? To realize it's a legitamate (albeit unblessed) system
>folder in the first place,

You're right, I was confused here.  I had forgotten that it is now
permitted again to have more than one system folder on a volume.  I
still think it's spooky to do so, though.

>you must *already* notice that there is a
>System and a Finder in that folder. You don't need to go looking in
>boot blocks to figure that out; you simply need to look at file types.

Well, I think that looking at vcbFndrInfo for the directory id of the
blessed folder is easier than looking at file types.  But yeah, if you
want to support unblessed system folders, you will have to scan the
files inside the folder.

I hadn't realized that the System and Finder files now had their own
unique type/creator.  Back on system 3 or so it was not uncommon for
people to create files with the same type/creator as the Finder, so
they wouldn't have to hassle with BNDL resources to give the file an
icon.  Apple started it (if memory serves me right, but I could be
wrong) by doing this with the Clipboard File and the Scrapbook File,
and then other vendors did the same with their "just-as-important"
data and preference files.

In light of that, are you sure that identifying the files by type/creator
is reliable?  I still find ZSYS/MACS and ZSYS/ERIK files on my disk that
were put there by current non-Apple software.  I know that System 7 now
uses zsys/MACS and FNDR/MACS for the System and Finder, but are you
sure that nobody is going to try to get a free icon out of the new codes
like they did out of the old ones?  And like many people do now by giving
their preferences files a type of 'pref'?

Related Question That May Answer This Question: How do the utility
programs that let you switch between system folders on the same volume
deal with the possibility that the folders might be in different
languages?  If they ignore the problem, using the System/Finder names
from the boot blocks, then you should also.  If they identify System/
Finder by their type/creator, as you are suggesting, and copy the
names to the boot blocks, then your argument gains a lot of support.

Similar Question:  What happens now when you copy files that have the
"wrong" names but the "right" type/creator into a folder on a volume
that does not already have a blessed folder?  That is, if I rename
System and Finder to something else, say "System copy" and "Finder copy",
and copy them into a folder on an otherwise blank disk, does that folder
get blessed?  Should it?  Do those names get copied to the boot blocks?
What if the names are longer than 15 bytes?  If the folder gets blessed,
that bolsters your contention that a system folder is defined in terms of
the types of the files within it, rather than their names.  And if not,
you are of course free to argue that this is yet another oversight that
ought to be corrected, but you will then have the additional burden of
convincing us that this would be the correct behavior.  You would have
to answer questions like: What if I have two finders in the same folder
under different names?  Which one is the real one?  What if I remove
one of them from the blessed folder?  Does the folder become unblessed,
or does the other finder get selected?  Which other one if I started
with more than two?

>Once you discover that there are appropriate System and Finder files
>using the file types, you can then open the appropriate one (I forget
>whether the fld# is in the System or the Finder; I believe it's the
>former) and do the GetResource from that file (I guess using
>Get1Resource instead of GetResource actually). You won't get the ones
>from the Swedish system since the Hindu (or whatever) system is the
>current resource file. It doesn't have to be the blessed folder since
>any system folder will be reasonable to put things into appropriate
>places.

You're right about the fld# resource being in the System file.  Too bad.
The resource map for the System file is huge, and it takes a while to
open it.  Of course, you only need to open it to get the folder names,
and you only need those if you are actually going to disburse files
into the appropriate subfolders, and you aren't going to do that until
the user responds to the dialog that comes up asking the user whether
it's OK to do so.  All of which means you could hide the time it takes
by doing it while the user is reading the dialog.

-Ron Hunsinger

+++++++++++++++++++++++++++

>From [e-mail] (ROBERT A. UHL )
Date: 11 May 94 21:53:07 GMT
Organization: University of Denver

In article <[e-mail]> [e-mail] (Zig Zichterman) writes:
>One place Apple violates its suggested guidelines in in the Finder's
>"About This Macintosh..." menu item. The Mac HI Guidelines book (pages 67-70)
>suggests that the ellipsis (...) should appear only on menu items that
>require *additional* information before they can complete (such as
>choosing a file from an Open... dialog, or setting up options in a
>Preferences... dialog, and so on). For menu items that execute without
>further information from the user, such as Cut, Copy, showing an About
>box, and so on, the ellipsis should not appear.

Oops...
I thought that the ellipsis indicated a dialog box (and, as far as I
know, that item is a dialog box).

>--Zig Zichterman
>[e-mail]
>


--
- -------------------------------------------------------
| Bob Uhl | Spectre                  | Christos Anesti! |
| U of D  | Baron Robert von Raetzin | Alithos Anesti!  |
- -------------------------------------------------------

---------------------------

>From [e-mail] (Eddy J. Gurney)
Subject: List Manager clikLoop problem... but whose it?
Date: Mon, 9 May 1994 22:02:04 GMT
Organization: Hewlett-Packard VCD

Over the weekend, I was adding some new features to some lists I have
in my app, and came across an interesting problem.  Running under Think
C 7, all optimizations on.

I have a List Manager click loop, declared as follows (yes, it is declared
pascal Boolean; I know a Pascal boolean is 1 bit and a C boolean is 16
bits... and that Think C should take care of everything for me :-)...

pascal Boolean MyClickLoop(void);

now, if MyClickLoop looks like this:

pascal Boolean MyClickLoop(void)
{
    Boolaen result = true;

    return true;
}

everything works as expected.

BUT if MyClickLoop uses something like this:

pascal Boolean MyClickLoop(void)
{
    Boolean result = true;

    return result;
}

it *DOESN'T* work.  I compared the disassembly of the two; nothing
out of the ordinary, really:

First version (at least the important parts):

LINK    A6
 ...
MOVE.B  #$01,$0008(A6)
UNLK    A6
RTS

Second version:

LINK    A6
MOVE.L  D7,-(A7)
MOVEQ   #$01,D7
 ...
MOVE.B  D7,$0008(A6)
MOVE.L  (A7)+,D7
UNLK    A6
RTS

Now, this shouldn't make any difference, EXCEPT that the List Manager
(_Pack0) calls the user-defined clikLoop routine with the following
code:

JSR     (A0)
BEQ     ...

As you can see, it immediately checks the Z condition code after the
routine finishes... which assumes that the last command executed in
the user-defined clikLoop routine sets that condition code correctly.
This is NOT the case in the second version, since the MOVE.L (A7)+,D7
(to restore the value of D7) clobbers the condition code set by the
MOVE.B D7,$0008(A6).  [If more than one register needed to be saved on
the stack and a MOVEM was used, this wouldn't matter since it doesn't
change the condition codes.  So this is kind of a "special" case (but
it SHOULD still work!)]  So my real clikLoop routine has a bunch of
"return true" and "return false" all over it, instead of a bunch of
"result = true" and "result = false" with one "return result" at the
end...

Anyway... whose problem is this?  Should Think C be "smart" enough to
work around this, or is the List Manager doing a Bad Thing by assuming
the condition codes are valid without first popping something off the
stack?

--
Eddy J. Gurney N8FPW   Hewlett-Packard Company, Vancouver (USA!) Division
[e-mail]                       #include <standard-disclaimer.h>
"Failures are divided into two classes-- those who thought and never did,
      and those who did and never thought."     John Charles Salak

+++++++++++++++++++++++++++

>From [e-mail] (Daniel Sears)
Date: Tue, 10 May 1994 05:23:17 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

Eddy,

your summary of the clikLoop problem was very good.
I've been having problems porting my clickLoop to the PPC
with its mixed mode madness and your summary clarified things.

On page 4-101 of Mo' Mac Toolbox, it says:

    A click-loop procedure should ordinarily set the Z flag to 1
    just before returning.  If a click-loop sets the Z flag to 0,
    then the LClick function immediately returns.

It later says in the Assembly Language Information section:

    Your click-loop procedure should ordinarily set register d0 to 1.
    To stop the LClick function from calling your procedure for the
    current mouse-down event, set register d0 to 0.

This second section could be a docubug or it could mean shut up,
just stop calling me.

As for whose problem this is, it sounds like a ThinkC code generation bug.
I can't think of any reason why

    return true; and result = true; return result; should be different.

Hope this helps.

Dan
--

E-mail:     [e-mail]
Phone:      [phone]
Address:    2440 16th Street #283
            San Francisco, CA 94103-4211

+++++++++++++++++++++++++++

>From [e-mail] (Marcel Blonk)
Date: Tue, 10 May 1994 08:32:14 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

: As for whose problem this is, it sounds like a ThinkC code generation bug.
: I can't think of any reason why

It's definitely not a Think C bug, since C compilers don't have anything
to do with returning condition codes as function results. Maybe the
Think C manual says somewhere that the CC return values are undefined (but
not likely, since there is NO reason at all to assume that the CC should
have any significance)

so:

:         return true; and result = true; return result; should be different.

are EXACTLY equal in C terms.

Who to blaim? Apple I'd have to say. Their documentation says to declare
the ClickLoop proc as a pascal Boolean returning function (in fact, the
assembly-language note only reasserts that). So, if in this case, the
ClickLoop is supposed to return with the Z-bit set appropiately, the
documentation should have said so (and should have indicated that this
routine can only be written with the appropiate assembler glue code)
(It's a strange peace of programming interface anyway, since it also
states that D5 contains the current mouse point "for your convenience".
That's a real no-no, if you ask me. The least they could have done, is
move D5 to D1 (it is eg. impossible to declare D5 as a pragma parameter,
only D0-D1 and A0-A1 (maybe one more), since that is the convention that
is used throughout the system)

Anyway, to conclude, seeing that the Z-bit has to be set appropiately, the
only way to write a proper ClickLoop function, is to add assembler glue
code. You can in no way rely on the C compiler to do this for you.

mb


+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Wed, 11 May 1994 14:06:00 +0800
Organization: NCRPDA, Curtin University

>On page 4-101 of Mo' Mac Toolbox, it says:
>
>        A click-loop procedure should ordinarily set the Z flag to 1
>        just before returning.  If a click-loop sets the Z flag to 0,
>        then the LClick function immediately returns.

This is correct for the 68k machines, at least in my experience.
>
>It later says in the Assembly Language Information section:
>
>        Your click-loop procedure should ordinarily set register d0 to 1.
>        To stop the LClick function from calling your procedure for the
>        current mouse-down event, set register d0 to 0.

This works only in that it sets the Z flag above.  My solution (in Pascal)
was to do it like this:

{$PUSH}
{$D-}
   function MyClickLoop: boolean;
{ returns the bloody equal flag for gods sake! }
   begin
      MyClickLoop := MyClickLoop2; { BE VERY CAREFUL!  Returns the equal flag! }
   end;
{$POP}

Comments left unchanged :-)
   Peter.
_______________________________________________________________________
Peter N Lewis <[e-mail]>       Ph: [phone]

+++++++++++++++++++++++++++

>From Dave Allcott <[e-mail]>
Date: 11 May 1994 14:32:18 GMT
Organization: Symantec Corporation

In article <[e-mail]> Daniel Sears, [e-mail] writes:
>As for whose problem this is, it sounds like a ThinkC code generation bug.
>I can't think of any reason why
>
>    return true; and result = true; return result; should be different.
>
>Hope this helps.

I thinks it's still arguable but I'll see what we can do about it in the future.
We should at least have oddities like this documented.

Dave

Depending on condition codes between function calls. tsk tsk. :)

---------------------------

>From Mark A. Saper <[e-mail]>
Subject: Opening a file with C standard i-o routines
Date: 9 May 1994 15:41:13 GMT
Organization: Biophysic, Univ. of Michigan

This is a question from a novice:

I am writing a drag and drop routine that handles AE's to open a
document.  The result from this is an FSSpec.  How can I use this to open
a file and read it with Think C's standard I/O routines like gets?  I can
open the file, read it into a buffer with Toolbox functions, but is there
any way to link the standard I/O stream with my allocated buffer?

Thanks for your help.
                                                                                                                        Mark Saper, [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Robert S. Mah)
Date: Mon, 09 May 1994 19:01:12 -0500
Organization: One Step Beyond

Mark A. Saper <[e-mail]> wrote:

> I am writing a drag and drop routine that handles AE's to open a
> document.  The result from this is an FSSpec.  How can I use this to open
> a file and read it with Think C's standard I/O routines like gets?  I can
> open the file, read it into a buffer with Toolbox functions, but is there
> any way to link the standard I/O stream with my allocated buffer?

Translate the FSSpec to a full pathname and then send that to fopen.
Code to do this is on the developer CD's and on ftp.apple.com in
/dts/mac/snippets/files/ (or somewhere like that)

Cheers,
Rob
___________________________________________________________________________
Robert S. Mah  -=-  One Step Beyond  -=-  212-947-6507  -=-  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (MarkS77)
Date: 9 May 1994 20:46:07 -0400
Organization: America Online, Inc. (1-800-827-6364)

This may not be the solution you want, but I've been extracting the file name,
using toolbox calls to set the current directory and just using the standard
C++ stream techniques to access the file.

Mark



+++++++++++++++++++++++++++

>From [e-mail] (Robert S. Mah)
Date: Tue, 10 May 1994 01:44:48 -0500
Organization: One Step Beyond

[e-mail] (MarkS77) wrote:

> This may not be the solution you want, but I've been extracting the file
> name, using toolbox calls to set the current directory and just using the
> standard C++ stream techniques to access the file.

Don't use working directory functions.  The main reason they exist is to
ensure backward compatibility with the old 400K disks (i.e. the MFS file
system).

If you need to use standard ANSI (or UNIX or C++ streams) files use the
full
pathname.  This is 100% safe and guaranteed to always work.  All it takes
is
the addition of 1 function to create the path name from the FSSpec.

Cheers,
Rob
___________________________________________________________________________
Robert S. Mah  -=-  One Step Beyond  -=-  212-947-6507  -=-  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (MarkS77)
Date: 10 May 1994 23:42:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail] (Robert
S. Mah) writes:

Don't use working directory functions.  The main reason they exist is to
ensure backward compatibility with the old 400K disks (i.e. the MFS file
system).


Actually, I usually get an SFReply from Standard File and use the
vRefNum to do a SetVol call. After this all I need is the file name
to do use standard C++ I/O. Are we talking about the same thing?

Mark

+++++++++++++++++++++++++++

>From [e-mail] (Robert S. Mah)
Date: Wed, 11 May 1994 01:06:17 -0500
Organization: One Step Beyond

[e-mail] (MarkS77) wrote:

> [e-mail] (Robert S. Mah) writes:
>
> Don't use working directory functions.  The main reason they exist is to
> ensure backward compatibility with the old 400K disks (i.e. the MFS file
> system).
>
> Actually, I usually get an SFReply from Standard File and use the
> vRefNum to do a SetVol call. After this all I need is the file name
> to do use standard C++ I/O. Are we talking about the same thing?

Yes, that's what I mean.  Don't use SetVol.  There's a tech note on it
that explains why and the inherent dangers.  Convert it to the full
pathname, it's much safer.

Cheers,
Rob
___________________________________________________________________________
Robert S. Mah  -=-  One Step Beyond  -=-  212-947-6507  -=-  [e-mail]

+++++++++++++++++++++++++++

>From Daniel C. Flatin <[e-mail]>
Date: 11 May 1994 15:49:05 GMT
Organization: Physics Dept., The Ohio State University

Here is how I use the Mac FSSpec and the standard io calls. I think I
got some of this information from "The Mac Programming Public Domain FAQ"


Dan Flatin
Physics Department
The Ohio State University
[e-mail]

/* ----------------------------------------------------------------------
    This is an fopen which uses a folder FSSpec for the file path instead
    of a full path name.
- -------------------------------------------------------------------- */
FILE    *fopenFS( char *name, FSSpec folder, const char *mode )
{
    FILE        *cFile;
    short       oldWDVol, oldTrueVol;
    long        oldDir, oldProc, folderID;

    cFile = nil;

    /* save current working directory */
    if ( GetVol( nil, &oldWDVol ) )
        return( nil );
    /* save current default volume info */
    if ( GetWDInfo( oldWDVol, &oldTrueVol, &oldDir, &oldProc ) )
        return( nil );
    FolderFFSpecToDirID( folder, &folderID );
    /* set selected info as default */
    if ( HSetVol( nil, folder.vRefNum, folderID ) )
        return( nil );

    fflush( nil );                      // flush all buffers

    cFile = fopen( name, mode );        // open the file

    HSetVol( nil, oldTrueVol, oldDir ); // restore default volume info

    SetVol( nil, oldWDVol );            // restore working directory
    return( cFile );
}


/* ----------------------------------------------------------------------
    This version of GetFOpen does not require a full path name to open
    the file. The use of full path names to identify files is frowned
    upon by Apple.
- -------------------------------------------------------------------- */
FILE    *GetFOpen( void )
{
    FILE                *cFile;
    StandardFileReply   mySFR;
    SFTypeList          myTypeList;
    char                name[64];
    short               oldWDVol, oldTrueVol;
    long                oldDir, oldProc;

    cFile = nil;

    myTypeList[0] = 'TEXT';
    StandardGetFile( nil, 1, myTypeList, &mySFR );

    if ( mySFR.sfGood )
    {
        /* save current working directory */
        if ( GetVol( nil, &oldWDVol ) )
            return( nil );
        /* save current default volume info */
        if ( GetWDInfo( oldWDVol, &oldTrueVol, &oldDir, &oldProc ) )
            return( nil );
        /* set selected info as default */
        if ( HSetVol( nil, mySFR.sfFile.vRefNum, mySFR.sfFile.parID ) )
            return( nil );

        PascalStrCpy( name, (char *)mySFR.sfFile.name );
        p2cstr( (unsigned char *)name );

        fflush( nil );                      // flush all buffers

        cFile = fopen( name, "r" );         // open the file

        HSetVol( nil, oldTrueVol, oldDir ); // restore default volume info

        SetVol( nil, oldWDVol );            // restore working directory
    }
    return( cFile );
}


/* ----------------------------------------------------------------------
    the folder FSSpec contains the volume reference number and the name.
    We need PBGetCatInfo() to get the directory ID. This routine does not
    (yet) check to see that the FFSpec does indeed describe a folder.
- -------------------------------------------------------------------- */
OSErr   FolderFFSpecToDirID( FSSpec folder, long *theDirID )
{
    CInfoPBRec              pb;
    OSErr                   err;

    pb.hFileInfo.ioCompletion = NULL;
    pb.hFileInfo.ioNamePtr = folder.name;
    pb.hFileInfo.ioVRefNum = folder.vRefNum;
    pb.hFileInfo.ioFDirIndex = 0;
    pb.hFileInfo.ioDirID = folder.parID;

    err = PBGetCatInfo( &pb, FALSE);

    if (  err == noErr)
        *theDirID = pb.dirInfo.ioDrDirID;
    else
        *theDirID = 0;

    return ( err );
}


/* ----------------------------------------------------------------------
    PascalStrCpy

    Just like strcpy except that it takes pascal strings as arguments.
- -------------------------------------------------------------------- */
char *PascalStrCpy( char *s1, char *s2 )
{
    *s1 = *s2;
    return( (char *)memcpy( s1+1, s2+1, *s1 ) );
}

---------------------------

>From [e-mail] (Eric Scouten)
Subject: Sym CDK vs CodeWarrior PPC: first impressions
Date: Tue, 10 May 1994 14:23:26 GMT
Organization: University of Minnesota, Student Affairs

Just got my copy of Symantec's CDK yesterday and ran some tests of it
against CodeWarrior PPC on a large application. (Don't consider these tests
scientific by any means; it's just a first glance.)

The application was the Art Class demo from Symantec's TCL 2.0 demos. For
SC++ I used it unmodified from the TCL 2.0.1 disks; for CW, I used the
version that was patched in my CW TCL port (see my earlier post on
comp.sys.mac.oop.tcl for details). Here are the stats:


 SC++ CDK    CW/PPC
 --------   --------
    10         12     Compile project from scratch (160+ files)
     4          1     Link/build application

   330K       415K    Final application size
    85K       1.5M    Number of lines compiled* (see explanation below)


Tests were conducted on my PowerMac 6100/60, 16MB RAM, 160MB disk, virtual
memory off, very few extensions (only those required for debugging).


Getting the CDK to run in 16MB is a hassle. I have to maintain two copies
of the Think Project Manager on my disk; one set for 5MB partition (for
compiling), the other set for 3.5MB (for linking, to share with the 8.5MB
ToolServer partition).

To me, the CDK package is *much* less attractive than the Symantec 68K
compiler or either CodeWarrior compiler. It lacks the quick
compile-link-run turnaround that the others have, and debugging is a step
down from awful.

I don't have two Macs sitting side-by-side to do debugging, so the Apple
debugger that's included with the package is completely useless. Even if I
could convince another debugger to work with the CDK-built apps, it would
be only minimally useful, since there's no access to symbolic information
-- the CDK compiler emits line numbers only.

To its credit, the CDK package produces much smaller code (note the almost
25% difference in app size above). I haven't tested execution speed between
the two compilers.


*Number of lines compiled: I attribute the relatively slow compile time for
CodeWarrior to the fact that most of the TCL headers couldn't be
precompiled. (CW doesn't allow class definitions in precompiled headers.
<hint, hint> ) Thus, CodeWarrior was compiling 17 times more code in only
20% more time. (!)

When CW is able to manage class definitions in the headers, there will be
no comparison! <hint, hint>


BTW, the Bedrock Exception Library is pretty flaky when compiled under
either PPC compiler. Fairly simple things, like opening too many new
documents, cause fatal crashes. (It does seem to be more stable when
compiled under Symantec's 68K compiler.)


-Eric


--
Eric Scouten * Univ of Minn * Student Affairs * Minneapolis, MN 55455 USA
             *  <[e-mail]>   * [phone]

I always thought that 'Intel Inside' was a warning required by
Truth in Advertising laws...
   -Anonymous

---------------------------

>From [e-mail] (Christopher James F Waters)
Subject: Where is the inheritance in AE objects?
Date: 26 Apr 1994 23:19:37 GMT
Organization: University of Auckland

I am writing my first scriptable application. After coming to grips with IM
InterApplication Communications and the AE registry it isn't really as
difficult as I expected. However there is one thing that puzzles me. The
registry talks about inheritance all the time and it is mentioned briefly in
IM but there doesn't seem to be any way that inheritance is enforced. Is it
up to me to ensure that all subclasses include the properties and elements
of their superclass? I would have thought that there would be a field in the
aete resource for specifying the superclass, then it wouldn't be necessary to
redfine properties and elements that have been defined previously.

Also, am I right in thinking that the aete shouldn't contain definitions for
abstract classes?

Chris Waters.
Department of Electrical & Electronic Engineering
University of Auckland.

+++++++++++++++++++++++++++

>From [e-mail] (Robert S. Mah)
Date: Tue, 26 Apr 1994 21:13:01 -0500
Organization: One Step Beyond

[e-mail] (Christopher James F Waters) wrote:

> registry talks about inheritance all the time and it is mentioned briefly
> in IM but there doesn't seem to be any way that inheritance is enforced.
> Is it up to me to ensure that all subclasses include the properties and
> elements of their superclass?

Yes.  The inheritance is conceptual only.

Cheers,
Rob
___________________________________________________________________________
Robert S. Mah  -=-  One Step Beyond  -=-  212-947-6507  -=-  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Paul G Smith)
Date: Wed, 27 Apr 94 12:49:03 GMT
Organization: commstalk, & Full Moon Software Inc


In article <2pk7i9$[e-mail]> (comp.sys.mac.programmer), [e-mail] (Christopher James F Waters) writes:
>
> I am writing my first scriptable application. After coming to grips with IM
> InterApplication Communications and the AE registry it isn't really as
> difficult as I expected. However there is one thing that puzzles me. The
> registry talks about inheritance all the time and it is mentioned briefly in
> IM but there doesn't seem to be any way that inheritance is enforced. Is it
> up to me to ensure that all subclasses include the properties and elements
> of their superclass? I would have thought that there would be a field in the
> aete resource for specifying the superclass, then it wouldn't be necessary to
> redfine properties and elements that have been defined previously.
>
> Also, am I right in thinking that the aete shouldn't contain definitions for
> abstract classes?
>
> Chris Waters.
> Department of Electrical & Electronic Engineering
> University of Auckland.
>

As it happens, the AppleScript 1.1 headers do define a constant you
can use to indicate object inheritance (this from ASRegistry.h):

    pInherits    = 0x6340235e,    //  'c@#^'  //

You can define a property, using this constant, to indicate an object
inherits the properties and elements of another class. Here is an
example of the aete definition for a sub-class:

        /* [4] */
        "my subclass",
        cSubClass,
        "A radio button",
        {    /* array Properties: 1 elements */
            /* [1] */
            "<inheritance>",
            pInherits,
            cSuperClass,
            "subclass of my superclass",
            reserved,
            singleItem,
            notEnumerated,
            readWrite,
            reserved, reserved, reserved, reserved,
            reserved, reserved, reserved, reserved, reserved,
            notFeminine,
            notMasculine,
            singular,
        },
        {    /* array Elements: 0 elements */
        },

The definition will say, to the user who examines your program
Dictionary using a Script Editor, that the class inherits from another;
the Dictionary display will format the property as something like:
    <inheritance> superclass name

The above is not the whole story. You do NOT have to duplicate all the
properties class by class, and the 'pInherits' property is no more than
a hint to the user, because AppleScript will allow any property,
declared anywhere in the aete, to be specified for 'get data' or 'set
data' for any class. In other words, AppleScript doesn't know or care
what object classes support what properties: it is up to the program
that is asked to resolve those properties to complain if an incorrect
property is specified. However, because users look to the Dictionary
to tell them what properties are valid for what object classes, you
should use the 'pInherits' mechanism to tell them what's going on.

Lastly, you might want to look out for the next issue of 'develop'
magazine, which includes an article I wrote about developing
OSA-savvy programs. It doesn't cover the 'pInherits' property, but it
does come with a lot of sample code that will be helpful to newcomers
to the OSA. ('develop' magazine is published by Apple Computer Inc.)


best regards, Paul

- --------------------------------------------------------------
Paul G Smith, Commstalk HQ          ||  UK ph: [phone]
P O Box 116, ST ALBANS              ||    fax: [phone]
Hertfordshire. AL1 2RL. UK          ||  US ph: 408 253 7199
& Full Moon Software, Inc           ||    fax: [phone]
P O Box 700237, SAN JOSE, CA 95170  ||  AppleLink: COMMSTALK.HQ

+++++++++++++++++++++++++++

>From [e-mail] (Alan B. Harper)
Date: Tue,  3 May 94 10:41:34 PST
Organization: Berkeley Macintosh Users Group

As far as I can tell, the "inheritance" in apple-event objects is purely for
the solopsistic inconvenience of the designer of the classes.  There seems to be

no support for inheritance, and there is no reason at all for abstract classes.

I have been proceeding by ignoring inheritance, and it doesn't seem to be a
problem.  I haven't written my aete yet, though.

BTW, is your application recordable?  How do you handle open events for
files?  As far as I can tell, the only way to send yourself an "open file" apple

event is to parse the FSSpec into an absolute file name and then send it to
yourself.
Do you know if there is a better way?

Alan

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 4 May 1994 07:40:33 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] (Alan B. Harper) writes:

>files?  As far as I can tell, the only way to send yourself an "open file" apple

>event is to parse the FSSpec into an absolute file name and then send it to
>yourself.
>Do you know if there is a better way?

Definately. You can put the FSSpec in the array of files, or you
can put aliases there, created by NewAlias. The latter is the most
preferrable.
--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe (on a Swedish scale) --

   "Just because you're paranoid(P) doesn't mean they aren't after(A) you"
          !(P -> !A) == !(!P | !A) == !(!(P & A)) == P & A

+++++++++++++++++++++++++++

>From [e-mail] (Leonard Rosenthol)
Date: Wed, 4 May 1994 17:42:46 GMT
Organization: Aladdin Systems, Inc.

In article <2q7jhh$[e-mail]>, [e-mail] (Jon Wdtte)
wrote:

> In <[e-mail]> [e-mail] (Alan B. Harper) writes:
>
> >files?  As far as I can tell, the only way to send yourself an "open
file" apple
>
> >event is to parse the FSSpec into an absolute file name and then send it to
> >yourself.
> >Do you know if there is a better way?
>
> Definately. You can put the FSSpec in the array of files, or you
> can put aliases there, created by NewAlias. The latter is the most
> preferrable.
>
   Yup,  that's the way.  And here is the code from my DropShell that
shows how to do it...

Leonard
- ---
/*
   This routine is the low level routine used by the SendODOCToSelf
   routine.  It gets passed the list of files (in an AEDescList)
   to be sent as the data for the 'odoc', builds up the event
   and sends off the event.

   It is broken out from SendODOCToSelf so that a SendODOCListToSelf could
   easily be written and it could then call this routine - but that is left
   as an exercise to the reader.

   Read the comments in the code for the order and details
*/
void _SendDocsToSelf (AEDescList *aliasList)
{
   OSErr       err;
   AEAddressDesc  theTarget;
   AppleEvent     openDocAE, replyAE;

/*
   First we create the target for the event.   We call another
   utility routine for creating the target.
*/
   err = GetTargetFromSelf(&theTarget);
   if (err == noErr) {
      /* Next we create the Apple event that will later get sent. */
      err = AECreateAppleEvent(kCoreEventClass, kAEOpenDocuments,
&theTarget, kAutoGenerateReturnID, kAnyTransactionID, &openDocAE);

      if (err == noErr) {
         /* Now add the aliasDescList to the openDocAE */
         err = AEPutParamDesc(&openDocAE, keyDirectObject, aliasList);

         if (err == noErr) {
            /*
               and finally send the event
               Since we are sending to ourselves, no need for reply.
            */
            err = AESend(&openDocAE, &replyAE, kAENoReply +
kAECanInteract, kAENormalPriority, 3600, NULL, NULL);

            /*
               NOTE: Since we are not requesting a reply, we do not need to
               need to dispose of the replyAE.  It is there simply as a
               placeholder.
            */
         }

      /*
         Dispose of the aliasList descriptor
         We do this instead of the caller since it needs to be done
         before disposing the AEVT
      */
         err = AEDisposeDesc(aliasList);
      }

   /*and of course dispose of the openDoc AEVT itself*/
      err = AEDisposeDesc(&openDocAE);
   }
}

/*
   This is the routine called by SelectFile to send a single odoc to ourselves.

   It calls the above low level routine to do the dirty work of sending
the AEVT -
   all we do here is build a AEDescList of the file to be opened.
*/
void SendODOCToSelf (FSSpec *theFileSpec) {

   OSErr    err;
   AEDescList  aliasList;
   AEDesc      aliasDesc;
   AliasHandle aliasH;

   /*Create the descList to hold the list of files*/
   err = AECreateList(NULL, 0, false, &aliasList);

   if (err == noErr) {
      /* First we setup the type of descriptor */
      aliasDesc.descriptorType = typeAlias;

      /*
         Now we add the file to descList by creating an alias and then
         adding it into the descList using AEPutDesc
      */
      err = NewAlias(NULL, theFileSpec, &aliasH);
      aliasDesc.dataHandle = (Handle)aliasH;
      err = AEPutDesc(&aliasList, 0, &aliasDesc);
      DisposHandle((Handle)aliasH);

      /*Now call the real gut level routine to do the dirty work*/
      _SendDocsToSelf(&aliasList);

      /*_SendDocsToSelf will dispose of aliasList for me*/
   }
}
- ------------------------------------------------------------------------
Leonard Rosenthol                      Internet:       [e-mail]
Director of Advanced Technology        AppleLink:      MACgician
Aladdin Systems, Inc.                  GEnie:          MACgician

+++++++++++++++++++++++++++

>From [e-mail] (Mike Cohen)
Date: Wed, 4 May 1994 17:45:41 GMT
Organization: ISIS International

[e-mail] (Alan B. Harper) writes:

>BTW, is your application recordable?  How do you handle open events for
>files?  As far as I can tell, the only way to send yourself an "open file" apple
>event is to parse the FSSpec into an absolute file name and then send it to
>yourself.
>Do you know if there is a better way?

>Alan

No, the open file event takes an alias, not a file name. It's very easy to
create an alias from a FSSpec (or, you could just send the FSSpec, since
there's a built-in coercion handler for alias <-> FSSpec.
--
Mike Cohen - [e-mail]
NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20

+++++++++++++++++++++++++++

>From [e-mail] (Dale M. Greer)
Date: 4 May 1994 19:57:23 GMT
Organization: The University of Texas at Dallas

Mike Cohen ([e-mail]) wrote:
> [e-mail] (Alan B. Harper) writes:

> >BTW, is your application recordable?  How do you handle open events for
> >files?  As far as I can tell, the only way to send yourself an "open file" apple
> >event is to parse the FSSpec into an absolute file name and then send it to
> >yourself.
> >Do you know if there is a better way?

> >Alan

> No, the open file event takes an alias, not a file name. It's very easy to
> create an alias from a FSSpec (or, you could just send the FSSpec, since
> there's a built-in coercion handler for alias <-> FSSpec.

It works with full file path names too.

--

Dale Greer, [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Wed, 04 May 1994 20:30:55 -0700
Organization: Internet for the Olympic Peninsula

In article <2q8un3$[e-mail]>, [e-mail] (Dale M.
Greer) wrote:

> Mike Cohen ([e-mail]) wrote:
> > [e-mail] (Alan B. Harper) writes:
>
> > >BTW, is your application recordable?  How do you handle open events for
> > >files?  As far as I can tell, the only way to send yourself an "open file" apple
> > >event is to parse the FSSpec into an absolute file name and then send it to
> > >yourself.
> > >Do you know if there is a better way?
>
> > >Alan
>
> > No, the open file event takes an alias, not a file name. It's very easy to
> > create an alias from a FSSpec (or, you could just send the FSSpec, since
> > there's a built-in coercion handler for alias <-> FSSpec.
>
> It works with full file path names too.

"It" only works with full path names if the application has prepared itself
for non-standard forms of the open document event, or something has
installed a system coercion for TEXT to FSSpec (TEXT to alias wouldn't help
typical applications).  Recently, "something" has indeed added a system
handler for TEXT to FSSpec...I believe that the something is AppleScript,
but it could be one of the apps running at this moment in my Mac.  But
there is one, which is why full path name works...relative path name
probably works, too.

The definition of the open document event calls for a list of aliases in
the direct parameter.  Since (a) an alias isn't what the application
ultimately wants (it wants an FSSpec) and (b) the Apple Event Manager will
coerce the alias to an FSSpec for you, and (c) even if something
[incorrectly] sends a single alias rather than a list of one alias, the
event handler should

1.  ask for the direct parameter as a list (if a single item was there, you
get a list of that one item, courtesy of the AE Manager)
2.  count the number of items in the list
3a.  ask for each item from the list, as an FSSpec (since that's how you
want them).
3b.  do something with each item.

The extended form of the open event has a list of object specifiers.
Conveniently, the needed coercions are in place so that you can ask for
those, instead of the above, if you support the extended form.  That too is
new since the beginning (again probably it is AppleScript doing it...easy
to test by starting without AppleScript).
--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jon Pugh)
Date: Wed, 11 May 1994 07:58:17 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

Alan B. Harper ([e-mail]) wrote:
> As far as I can tell, the "inheritance" in apple-event objects is purely for
> the solopsistic [sic] inconvenience of the designer of the classes.  There
> seems to be no support for inheritance, and there is no reason at all for
> abstract classes.

> I have been proceeding by ignoring inheritance, and it doesn't seem to be a
> problem.  I haven't written my aete yet, though.

This is essentially correct.  You do not need to worry about abstract classes
and there is no support for any objects, only their resolution.  Your OSL
callbacks do all the object stuff and they can be object oriented.  I'm doing
some abstract inherited objects in my current project.  I have an app with
two document types.  Since I want to be able to talk about documents, docfoos
and docbars, it makes sense to subclass them and implement them as inherited
objects.

As usual, all the work is on my shoulders, but I'm used to that.  ;)

Jon


---------------------------

>From [e-mail] (Alexander Perlis)
Subject: [Q] How to prevent _DragWindow from selecting the window?
Date: 9 May 1994 20:32:29 GMT
Organization: Louisiana State University InterNetNews Site

The _DragWindow trap follows the mouse with an outline of a window and
then moves the window to the new location when the user releases the
mouse. After moving the window, unless the user held down the command-key
when initiating the drag, the window is also selected.

I would like to let users move non-frontmost windows around even when the
frontmost window is modal and must remain frontmost. If I could fake
_DragWindow into thinking that the command-key had been held down on the
previous mouseDown event, I'd be in business. Or if I could patch into
_DragWindow in the appropriate place to prevent the window selection, I
would also be in business.

However, tracing through the _DragWindow code is hopeless for my
less-than-perfect abilities because this routine is in various pieces
which involve calls to the infamous Layer Manager which we are not
supposed to touch and not even supposed to try to understand. Patching
_DragWindow seems to be a bad idea.

How can I convince _DragWindow that the command-key was held down? Or is
there a better or more obvious way to prevent _DragWindow from selecting
the window after the drag?

Mystified,
Alexander Perlis
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Dean Yu)
Date: 10 May 1994 02:36:17 GMT
Organization: General Magic, Inc.

In article <2qm6kt$[e-mail]>, [e-mail]
(Alexander Perlis) wrote:
> How can I convince _DragWindow that the command-key was held down? Or is
> there a better or more obvious way to prevent _DragWindow from selecting
> the window after the drag?

  How about not calling DragWindow, and calling DragGrayRgn instead? If you
want to be really cool, you can call ClipAbove first so that the region is
clipped behind any window that is above the one that you're dragging. When
the user lets up, you can then call MoveWindow to move the window, passing
false in the front parameter to keep the window where it is.

-- Dean Yu
   Negative Ethnic Role Model
   General Magic, Inc.

+++++++++++++++++++++++++++

>From Guenther Blaschek <[e-mail]>
Date: Tue, 10 May 1994 10:16:02 CDT
Organization: University of Linz, Austria

In article <dean-090594193343@dean_yu.genmagic.com> Dean Yu, [e-mail]
writes:
>> How can I convince _DragWindow that the command-key was held down? Or is
>> there a better or more obvious way to prevent _DragWindow from selecting
>> the window after the drag?
>
>  How about not calling DragWindow, and calling DragGrayRgn instead? If you
>want to be really cool, you can call ClipAbove first so that the region is
>clipped behind any window that is above the one that you're dragging. When
>the user lets up, you can then call MoveWindow to move the window, passing
>false in the front parameter to keep the window where it is.

Here's how I did it:

VAR
  windH,windV:Integer; {global variables}

PROCEDURE MyMoveWindow (theWindow: WindowPtr; h, v: Integer; front: Boolean);
  BEGIN
    windH := h;
    windV := v
  END;

PROCEDURE MyDragWindow (w: WindowPtr; pt: Point; bounds: Rect);
  VAR
    oldA5, oldMove: LongInt;
  BEGIN
    oldA5 := SetCurrentA5;
    oldMove := GetTrapAddress($A91B); {MoveWindow}
    SetTrapAddress(LongInt(@MyMoveWindow), $A91B); {patch MoveWindow}
    windH := -32000;
    DragWindow(w, pt, bounds);
    SetTrapAddress(oldMove, $A91B); {restore the patch}
    IF windH <> -32000 THEN {only if MyMoveWindow was called}
      MoveWindow(w, windH, windV, FALSE); {never move the window to front}
    oldA5 := SetA5(oldA5)
  END;

Call MyDragWindow instead of DragWindow.
MyDragWindow temporarily patches MoveWindow by replacing it with MyMoveWindow.
MyMoveWindow simply remembers the position where the window should be moved.
If windH<>-32000 (i.e., if MyMoveWindow was called during DragWindow), the
original MoveWindow is called with the last parameter set to FALSE, which
makes MoveWindow behave as if the command key had been pressed.

 e -- Guenther Blaschek                Tel.:   [phone]
gu -- Johannes Kepler University Linz  Fax:    [phone]
        Institute of Computer Science  e-Mail: [e-mail]
                  Software Department          [e-mail]
                   Altenbergerstr. 69
                 A-4040 Linz, Austria

+++++++++++++++++++++++++++

>From [e-mail] (Kevin R. Boyce)
Date: Tue, 10 May 1994 12:23:16 -0400
Organization: NASA/GSFC

[e-mail] (Alexander Perlis) wrote:

> The _DragWindow trap follows the mouse with an outline of a window and
> then moves the window to the new location when the user releases the
> mouse. After moving the window, unless the user held down the command-key
> when initiating the drag, the window is also selected.

Here's some code that does what Dean Yu suggested (without using ClipAbove
-- that would add to the coolness).  This is a part of my DoMouseDown
routine.


    short        windowPart;
    WindowPtr    whichWindow;
    RgnHandle    rgn, clipRgn;
    Rect        r;
    long        lDistVH;
    short        h,v;
    GrafPtr        savePort;

    ...

    windowPart = FindWindow(evp->where, &whichWindow);
    switch(windowPart)
    {
    case inDrag:
        if( progDialog == whichWindow || psStopped == processingState )
        {
            /*
             * Just do a normal drag.
             */
            DragWindow(whichWindow, evp->where, &dragRect);
        }
        else
        {
            /*
             * If we're processing, and trying to drag the main window,
             * drag it but don't select it.  (We don't want to allow the user
             * to change any settings while processing.)  Calling DragWindow()
             * generates an activate event (and activates the frame) unless
             * the command key is held down.  Turning on cmdKey in the event
             * (*evp) doesn't help; DragWindow must check the keyboard.  Yuck.
             * So I drag it by hand.
             */
            GetPort( &savePort );
            SetPort( WMgrPort );
            rgn = NewRgn();
            clipRgn = NewRgn();
            GetClip( clipRgn );
            ClipRect( &screenBits.bounds );
            r = (*((WindowPeek)whichWindow)->strucRgn)->rgnBBox;
            RectRgn( rgn, &r );
            r = (*((WindowPeek)whichWindow)->contRgn)->rgnBBox;
            h = r.left - evp->where.h;
            v = r.top - evp->where.v;
            lDistVH = DragGrayRgn( rgn, evp->where, &dragRect, &dragRect, 0, nil );
            if( lDistVH != 0x80008000 )
            {
                h += evp->where.h + ( lDistVH & 0xFFFF );
                v += evp->where.v + ( (lDistVH & 0xFFFF0000) >> 16 );
                MoveWindow( whichWindow, h, v, FALSE );
            }
            SetClip( clipRgn );
            SetPort( savePort );
            DisposeRgn( rgn );
            DisposeRgn( clipRgn );
        }
        break;

It works in my program, on my machine, with my system.  Anything else is
not guaranteed.  But at least it gets the local<->global coordinate
transformation right.
--
Kevin      [e-mail]
You can blow out a candle, but you can't blow out a fire.
Once the flame begin to catch, the wind will blow it higher.
           --Peter Gabriel, 1980  _Biko_

+++++++++++++++++++++++++++

>From [e-mail] (Dean Yu)
Date: 10 May 1994 16:47:56 GMT
Organization: General Magic, Inc.

In article <19940510.101602449417.NETNEWS@ALIJKU11>, Guenther Blaschek
<[e-mail]> wrote:
> Call MyDragWindow instead of DragWindow.
> MyDragWindow temporarily patches MoveWindow by replacing it with MyMoveWindow.
> MyMoveWindow simply remembers the position where the window should be moved.
> If windH<>-32000 (i.e., if MyMoveWindow was called during DragWindow), the
> original MoveWindow is called with the last parameter set to FALSE, which
> makes MoveWindow behave as if the command key had been pressed.

  This is really gross and is exactly why I tell people not to patch
things. This code assumes that DragWindow calls MoveWindow to move the
window after the drag is done. Sure, it's true today but it might not be
tomorrow. If someone like Microsoft makes this assumption, it shackles
system software from ever changing.
  Roll your own. Don't patch.

-- Dean Yu
   Negative Ethnic Role Model
   General Magic, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 10 May 1994 17:25:26 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] (Kevin R. Boyce) writes:

>            GetClip( clipRgn );
>            ClipRect( &screenBits.bounds );

This won't work when you have more than one screen.
You should use
            SetClip ( GetGrayRgn ( ) ) ;
instead.

Interesting trivia: you can pass something "sufficiently close" to
what screenBits . bounds is as a limnitRect to DragWindow; the
toolbox will check for that case and figure out you mean to drag
the window within the whole gray region instead. Talk about
compatibility hack...

--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe (on a Swedish scale) --
   The word "politics" is derived from the word "poly", meaning
   "many", and the word "ticks", meaning "blood sucking parasites".
                     -- Larry Hardiman

+++++++++++++++++++++++++++

>From Guenther Blaschek <[e-mail]>
Date: Wed, 11 May 1994 09:29:07 CDT
Organization: University of Linz, Austria

In article <dean-100594094430@dean_yu.genmagic.com> Dean Yu, [e-mail]
writes:
>> Call MyDragWindow instead of DragWindow.
>> MyDragWindow temporarily patches MoveWindow by replacing it with
MyMoveWindow.
>> MyMoveWindow simply remembers the position where the window should be moved.
>> If windH<>-32000 (i.e., if MyMoveWindow was called during DragWindow), the
>> original MoveWindow is called with the last parameter set to FALSE, which
>> makes MoveWindow behave as if the command key had been pressed.
>
>  This is really gross and is exactly why I tell people not to patch
>things. This code assumes that DragWindow calls MoveWindow to move the
>window after the drag is done. Sure, it's true today but it might not be
>tomorrow. If someone like Microsoft makes this assumption, it shackles
>system software from ever changing.
>  Roll your own. Don't patch.

It is correct that the code assumes that DragWindow calls MoveWindow,
but I did not guess that or get this knowledge thru experiments.
Rather, IT'S DOCUMENTED IN INSIDE MACINTOSH!

IM Vol. I, p. 289:
"... When the mouse button is released, DragWindow calls MoveWindow to move
theWindow to the location to which it was dragged. If theWindow isn't the
active window (and the Command key wasn't being held down), DragWindow
makes it the active window by passing TRUE for the front parameter when
calling MoveWindow. ..."

I believe that temporarily patching MoveWindow is actually safer than
re-implementing DragWindow. If, for some reason, the mechanism to move
windows changed, the re-implementation would not work any longer, whereas
my solution would still work because the new DragWindow would be called
which would then call MoveWindow -- and that's guaranteed because it is
documented.

 e -- Guenther Blaschek                Tel.:   [phone]
gu -- Johannes Kepler University Linz  Fax:    [phone]
        Institute of Computer Science  e-Mail: [e-mail]
                  Software Department          [e-mail]
                   Altenbergerstr. 69
                 A-4040 Linz, Austria

---------------------------

>From [e-mail] (Brian Park)
Subject: [Q] casting Str255 <--> (char*)
Date: 6 May 1994 21:07:07 GMT
Organization: Stanford University

I'm having a little problem understanding casting a (char*) to
(Str255), with strict prototype checks.
Consider the following small code segment in THNIK C 7.0:

void do_pascal(Str255 p);
void do_c(char *c)
{
    char t[256];

    strcpy(t, c);
    CtoPStr(t);
    do_pascal(t);    /* gives compile time error here */
}

It gives an error, saying prototype doesn't match.  Now I try

    do_pascal((Str255)t);    /* error */
    do_pascal((Str255*)t);    /* error */
    do_pascal(*(Str255*)t); /* compiles */

Obviously, I thought I understood C strings/arrays, but I don't.
Shouldn't the first one work?  I don't even understand what the
third one is saying, "convert t into a pointer to a pointer to array
of 256 characters, then convert it to a pointer to an array of 256 char"?
That's what I said in the first one. :-)

Brian Park

+++++++++++++++++++++++++++

>From Carl R. Osterwald <[e-mail]>
Date: Fri, 6 May 1994 00:16:10 GMT
Organization: National Renewable Energy Laboratory

In article <2qebhr$[e-mail]> Brian Park,
[e-mail] writes:
>I'm having a little problem understanding casting a (char*) to
>(Str255), with strict prototype checks.
>Consider the following small code segment in THNIK C 7.0:
>
>void do_pascal(Str255 p);
>void do_c(char *c)
>{
>    char t[256];
>
>    strcpy(t, c);
>    CtoPStr(t);
>    do_pascal(t);    /* gives compile time error here */
/****argument does not match prototype****/
>}
>
>It gives an error, saying prototype doesn't match.  Now I try
>
>    do_pascal((Str255)t);    /* error */
/****illegal cast****/
>    do_pascal((Str255*)t);    /* error */
/****argument does not match prototype****/
>    do_pascal(*(Str255*)t); /* compiles */

The Macintosh header files define Pascal strings with _unsigned chars_,
like:
  unsigned char Str255[256], Str63[64], Str31[32], *StringPtr;

So the argument to do_pascal is really a pointer to an unsigned char.
Your first attempt to call do_pascal is rejected because t is a pointer
to a normal c char.  The second fails because you are trying to cast a
pointer into an array.  The third fails because you cast a pointer to an
unsigned char into a pointer to an array, which is different to the
compiler.  The last one works (compiles) because you dereference the
pointer to an array.  I don't think it will give the right answer,
though.  So, you can change the do_pascal call to:
  do_pascal( (unsigned char *)t );

Better yet, change the argument to do_pascal to a StringPtr, and you end
up with:
void do_pascal(StringPtr p);
void do_c(char *c)
{
    char t[256];

    strcpy(t, c);
    CtoPStr(t);
    do_pascal( (StringPtr)t );
}

+++++++++++++++++++++++++++

>From Shahid Alam <[e-mail]>
Date: 7 May 1994 00:07:25 GMT
Organization: UT Austin/General Libraries/Library Systems

In article <2qebhr$[e-mail]> Brian Park,
[e-mail] writes:
> I'm having a little problem understanding casting a (char*) to
> (Str255), with strict prototype checks.
> Consider the following small code segment in THNIK C 7.0:
>
> void do_pascal(Str255 p);
> void do_c(char *c)
> {
>     char t[256];
>
>     strcpy(t, c);
>     CtoPStr(t);
>     do_pascal(t);    /* gives compile time error here */
> }

The definition of Str255 is

    typedef unsigned char Str255[256];
            ^^^^^^^^
It's that unsigned that's causing this statement to be flagged as an
error:

    char[256]   <>    unsigned char[256]

With complete typechecking this conversion must be explicit. However,
explicit conversion is also a problem since, you cannot typecast to
array.  Arrays, while glorified pointers, are special in that they
cannot represent an lvalue, and similarly cannot be cast to. Which is
what your problem in the next statement is:

>
> It gives an error, saying prototype doesn't match.  Now I try
>
>     do_pascal((Str255)t);    /* error */

In order to cast to an array you must cast to the pointer to the array.
The following does not work however, because here you are basically
typecasting a "char[256]", conceptually same as "char*" in C, which is
what t is, to a "unsigned char[256]*", conceptually "unsigned char**",
thus the problem.


>     do_pascal((Str255*)t);    /* error */

And the following typecast, "char[256]*" (pointer to t, or pointer to
array of char) to "unsigned char[256]*" (String255*, or pointer to an
array of unsigned char), works:

>     do_pascal(*(Str255*)t); /* compiles */
>
> Obviously, I thought I understood C strings/arrays, but I don't.
> Shouldn't the first one work?  I don't even understand what the
> third one is saying, "convert t into a pointer to a pointer to array
> of 256 characters, then convert it to a pointer to an array of 256 char"?
> That's what I said in the first one. :-)

This is all as I understand it.  I don't have K&R handy.  If I am mistaken,
I'm sure somebody will be kind enough to point it out.

> Brian Park
_____________________________________________________________________________
Shahid M. Alam
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Brian Park)
Date: 9 May 1994 02:12:33 GMT
Organization: Stanford University

Carl R. Osterwald  <[e-mail]> wrote:
>So the argument to do_pascal is really a pointer to an unsigned char.
[...]
>  do_pascal( (unsigned char *)t );

yes, yes!  Now I get it!  I did know that (char *) != (unsigned char *),
but didn't connect it to this problem.  Feel pretty stupid now.
I still think that casting to (Str255) should be legal but who am I to
argue with a compiler?  As Carl suggested, the proper way around all
this is to use the pre-defined type StringPtr.  Thanks all.

Brian Park

---------------------------

End of C.S.M.P. Digest
**********************